【MySQL】MySQL索引背后的之使用策略及优化【转】

转自：http://database.ctocio.com.cn/353/11664853.shtml

另外很不错的对于索引及索引优化的文章：

http://www.cnblogs.com/magialmoon/archive/2013/11/23/3439042.html

http://www.cnblogs.com/baochuan/archive/2012/05/23/2513224.html 

索引的使用

　　示例数据库

　　为了讨论索引策略，须要一个数据量不算小的数据库做为示例。本文选用MySQL官方文档中提供的示例数据库之一：employees。这个数据库关系复杂度适中，且数据量较大。下图是这个数据库的E-R关系图(引用自MySQL官方手册)：

　　MySQL官方文档中关于此数据库的页面为http://dev.mysql.com/doc/employee/en/employee.html。里面详细介绍了此数据库，并提供了下载地址和导入方法，若是有兴趣导入此数据库到本身的MySQL能够参考文中内容。

　　最左前缀原理与相关优化

　　高效使用索引的首要条件是知道什么样的查询会使用到索引，这个问题和B+Tree中的“最左前缀原理”有关，下面经过例子说明最左前缀原理。

　　这里先说一下联合索引的概念。在上文中，咱们都是假设索引只引用了单个的列，实际上，MySQL中的索引能够以必定顺序引用多个列，这种索引叫作联合索引，通常的，一个联合索引是一个有序元组，其中各个元素均为数据表的一列，实际上要严格定义索引须要用到关系代数，可是这里我不想讨论太多关系代数的话题，由于那样会显得很枯燥，因此这里就再也不作严格定义。另外，单列索引能够当作联合索引元素数为1的特例。

　　以employees.titles表为例，下面先查看其上都有哪些索引：

如下是代码片断：
SHOW INDEX FROM employees.titles; 
+--------+------------+----------+--------------+-------------+-----------+-------------+------+------------+
| Table | Non_unique | Key_name | Seq_in_index | Column_name | Collation | Cardinality | Null | Index_type | 
+--------+------------+----------+--------------+-------------+-----------+-------------+------+------------+
| titles | 0 | PRIMARY | 1 | emp_no | A | NULL | | BTREE | 
| titles | 0 | PRIMARY | 2 | title | A | NULL | | BTREE | 
| titles | 0 | PRIMARY | 3 | from_date | A | 443308 | | BTREE | 
| titles | 1 | emp_no | 1 | emp_no | A | 443308 | | BTREE | 
+--------+------------+----------+--------------+-------------+-----------+-------------+------+------------+

　　从结果中能够到titles表的主索引为<emp_no, title,="" from_date="">，还有一个辅助索引<emp_no>。为了不多个索引使事情变复杂(MySQL的SQL优化器在多索引时行为比较复杂)，这里咱们将辅助索引drop掉：

如下是代码片断：
ALTER TABLE employees.titles DROP INDEX emp_no;

　　这样就能够专心分析索引PRIMARY的行为了。

　　状况一：全列匹配。

如下是代码片断：
EXPLAIN SELECT * FROM employees.titles WHERE emp_no='10001' AND title='Senior Engineer' AND from_date='1986-06-26'; 
+----+-------------+--------+-------+---------------+---------+---------+-------------------+------+-------+
| id | select_type | table | type | possible_keys | key | key_len | ref | rows | Extra | 
+----+-------------+--------+-------+---------------+---------+---------+-------------------+------+-------+
| 1 | SIMPLE | titles | const | PRIMARY | PRIMARY | 59 | const,const,const | 1 | | 
+----+-------------+--------+-------+---------------+---------+---------+-------------------+------+-------+

　　很明显，当按照索引中全部列进行精确匹配(这里精确匹配指“=”或“IN”匹配)时，索引能够被用到。这里有一点须要注意，理论上索引对顺序是敏感的，但 是因为MySQL的查询优化器会自动调整where子句的条件顺序以使用适合的索引，例如咱们将where中的条件顺序颠倒：

如下是代码片断：
EXPLAIN SELECT * FROM employees.titles WHERE from_date='1986-06-26' AND emp_no='10001' AND title='Senior Engineer'; 
+----+-------------+--------+-------+---------------+---------+---------+-------------------+------+-------+
| id | select_type | table | type | possible_keys | key | key_len | ref | rows | Extra | 
+----+-------------+--------+-------+---------------+---------+---------+-------------------+------+-------+
| 1 | SIMPLE | titles | const | PRIMARY | PRIMARY | 59 | const,const,const | 1 | | 
+----+-------------+--------+-------+---------------+---------+---------+-------------------+------+-------+

　　效果是同样的。

　　状况二：最左前缀匹配。

如下是代码片断：
EXPLAIN SELECT * FROM employees.titles WHERE emp_no='10001'; 
+----+-------------+--------+------+---------------+---------+---------+-------+------+-------+ 
| id | select_type | table | type | possible_keys | key | key_len | ref | rows | Extra | 
+----+-------------+--------+------+---------------+---------+---------+-------+------+-------+ 
| 1 | SIMPLE | titles | ref | PRIMARY | PRIMARY | 4 | const | 1 | | 
+----+-------------+--------+------+---------------+---------+---------+-------+------+-------+

　　当查询条件精确匹配索引的左边连续一个或几个列时，如<emp_no>或<emp_no, title="">，因此能够被用到，可是只能用到一部分，即条件所组成的最左前缀。上面的查询从分析结果看用到了PRIMARY索引，可是 key_len为4，说明只用到了索引的第一列前缀。

　　状况三：查询条件用到了索引中列的精确匹配，可是中间某个条件未提供。

如下是代码片断：
EXPLAIN SELECT * FROM employees.titles WHERE emp_no='10001' AND from_date='1986-06-26'; 
+----+-------------+--------+------+---------------+---------+---------+-------+------+-------------+ 
| id | select_type | table | type | possible_keys | key | key_len | ref | rows | Extra | 
+----+-------------+--------+------+---------------+---------+---------+-------+------+-------------+ 
| 1 | SIMPLE | titles | ref | PRIMARY | PRIMARY | 4 | const | 1 | Using where | 
+----+-------------+--------+------+---------------+---------+---------+-------+------+-------------+

　　此时索引使用状况和状况二相同，由于title未提供，因此查询只用到了索引的第一列，然后面的from_date虽然也在索引中，可是因为 title不存在而没法和左前缀链接，所以须要对结果进行扫描过滤from_date(这里因为emp_no惟一，因此不存在扫描)。若是想让 from_date也使用索引而不是where过滤，能够增长一个辅助索引<emp_no, from_date="">，此时上面的查询会使用这个索引。除此以外，还可使用一种称之为“隔离列”的优化方法，将emp_no与from_date 之间的“坑”填上。

　　首先咱们看下title一共有几种不一样的值：

如下是代码片断：
SELECT DISTINCT(title) FROM employees.titles; 
+--------------------+ 
| title | 
+--------------------+ 
| Senior Engineer | 
| Staff | 
| Engineer | 
| Senior Staff | 
| Assistant Engineer | 
| Technique Leader | 
| Manager | 
+--------------------+

　　只有7种。在这种成为“坑”的列值比较少的状况下，能够考虑用“IN”来填补这个“坑”从而造成最左前缀： 

如下是代码片断：
EXPLAIN SELECT * FROM employees.titles 
WHERE emp_no='10001' 
AND title IN ('Senior Engineer', 'Staff', 'Engineer', 'Senior Staff', 'Assistant Engineer', 'Technique Leader', 'Manager') 
AND from_date='1986-06-26'; 
+----+-------------+--------+-------+---------------+---------+---------+------+------+-------------+ 
| id | select_type | table | type | possible_keys | key | key_len | ref | rows | Extra | 
+----+-------------+--------+-------+---------------+---------+---------+------+------+-------------+ 
| 1 | SIMPLE | titles | range | PRIMARY | PRIMARY | 59 | NULL | 7 | Using where | 
+----+-------------+--------+-------+---------------+---------+---------+------+------+-------------+

　　此次key_len为59，说明索引被用全了，可是从type和rows看出IN实际上执行了一个range查询，这里检查了7个key。看下两种查询的性能比较：

如下是代码片断：
SHOW PROFILES; 
+----------+------------+-------------------------------------------------------------------------------+ 
| Query_ID | Duration | Query | 
+----------+------------+-------------------------------------------------------------------------------+ 
| 10 | 0.00058000 | SELECT * FROM employees.titles WHERE emp_no='10001' AND from_date='1986-06-26'| 
| 11 | 0.00052500 | SELECT * FROM employees.titles WHERE emp_no='10001' AND title IN ... | 
+----------+------------+-------------------------------------------------------------------------------+

　　“填坑”后性能提高了一点。若是通过emp_no筛选后余下不少数据，则后者性能优点会更加明显。固然，若是title的值不少，用填坑就不合适了，必须创建辅助索引。

　　状况四：查询条件没有指定索引第一列。

如下是代码片断：
EXPLAIN SELECT * FROM employees.titles WHERE from_date='1986-06-26'; 
+----+-------------+--------+------+---------------+------+---------+------+--------+-------------+ 
| id | select_type | table | type | possible_keys | key | key_len | ref | rows | Extra | 
+----+-------------+--------+------+---------------+------+---------+------+--------+-------------+ 
| 1 | SIMPLE | titles | ALL | NULL | NULL | NULL | NULL | 443308 | Using where | 
+----+-------------+--------+------+---------------+------+---------+------+--------+-------------+

　　因为不是最左前缀，索引这样的查询显然用不到索引。

　　状况五：匹配某列的前缀字符串。

1 如下是代码片断：
2 EXPLAIN SELECT * FROM employees.titles WHERE emp_no='10001' AND title LIKE 'Senior%'; 
3 view sourceprint? 
4 +----+-------------+--------+-------+---------------+---------+---------+------+------+-------------+ 
5 | id | select_type | table | type | possible_keys | key | key_len | ref | rows | Extra | 
6 +----+-------------+--------+-------+---------------+---------+---------+------+------+-------------+ 
7 | 1 | SIMPLE | titles | range | PRIMARY | PRIMARY | 56 | NULL | 1 | Using where | 
8 +----+-------------+--------+-------+---------------+---------+---------+------+------+-------------+

　　此时能够用到索引，可是若是通配符不是只出如今末尾，则没法使用索引，例如like '%x%'或‘%x’都没法使用到索引。

　　状况六：范围查询。

1 如下是代码片断：
2 EXPLAIN SELECT * FROM employees.titles WHERE emp_no<'10010' and title='Senior Engineer'; 
3 +----+-------------+--------+-------+---------------+---------+---------+------+------+-------------+ 
4 | id | select_type | table | type | possible_keys | key | key_len | ref | rows | Extra | 
5 +----+-------------+--------+-------+---------------+---------+---------+------+------+-------------+ 
6 | 1 | SIMPLE | titles | range | PRIMARY | PRIMARY | 4 | NULL | 16 | Using where | 
7 +----+-------------+--------+-------+---------------+---------+---------+------+------+-------------+

　　范围列能够用到索引(必须是最左前缀)，可是范围列后面的列没法用到索引。同时，索引最多用于一个范围列，所以若是查询条件中有两个范围列则没法全用到索引。

 1 如下是代码片断：
 2 EXPLAIN SELECT * FROM employees.titles 
 3 WHERE emp_no<'10010' 
 4 AND title='Senior Engineer' 
 5 AND from_date BETWEEN '1986-01-01' AND '1986-12-31'; 
 6 +----+-------------+--------+-------+---------------+---------+---------+------+------+-------------+ 
 7 | id | select_type | table | type | possible_keys | key | key_len | ref | rows | Extra | 
 8 +----+-------------+--------+-------+---------------+---------+---------+------+------+-------------+ 
 9 | 1 | SIMPLE | titles | range | PRIMARY | PRIMARY | 4 | NULL | 16 | Using where | 
10 +----+-------------+--------+-------+---------------+---------+---------+------+------+-------------+

　　能够看到索引对第二个范围索引无能为力。这里特别要说明MySQL一个有意思的地方，那就是仅用explain可能没法区分范围索引和多值匹配，由于在type中这二者都显示为range。同时，用了“between”并不意味着就是范围查询，例以下面的查询：

 1 如下是代码片断：
 2 EXPLAIN SELECT * FROM employees.titles 
 3 WHERE emp_no BETWEEN '10001' AND '10010' 
 4 AND title='Senior Engineer' 
 5 AND from_date BETWEEN '1986-01-01' AND '1986-12-31'; 
 6 +----+-------------+--------+-------+---------------+---------+---------+------+------+-------------+ 
 7 | id | select_type | table | type | possible_keys | key | key_len | ref | rows | Extra | 
 8 +----+-------------+--------+-------+---------------+---------+---------+------+------+-------------+ 
 9 | 1 | SIMPLE | titles | range | PRIMARY | PRIMARY | 59 | NULL | 16 | Using where | 
10 +----+-------------+--------+-------+---------------+---------+---------+------+------+-------------+

　　看起来是用了两个范围查询，但做用于emp_no上的“BETWEEN”实际上至关于“IN”，也就是说emp_no实际是多值精确匹配。能够看到这个查询用到了索引所有三个列。所以在MySQL中要谨慎地区分多值匹配和范围匹配，不然会对MySQL的行为产生困惑。

1 如下是代码片断：
2 EXPLAIN SELECT * FROM employees.titles WHERE emp_no='10001' AND left(title, 6)='Senior'; 
3 +----+-------------+--------+------+---------------+---------+---------+-------+------+-------------+ 
4 | id | select_type | table | type | possible_keys | key | key_len | ref | rows | Extra | 
5 +----+-------------+--------+------+---------------+---------+---------+-------+------+-------------+ 
6 | 1 | SIMPLE | titles | ref | PRIMARY | PRIMARY | 4 | const | 1 | Using where | 
7 +----+-------------+--------+------+---------------+---------+---------+-------+------+-------------+

 　　虽然这个查询和状况五中功能相同，可是因为使用了函数left，则没法为title列应用索引，而状况五中用LIKE则能够。再如：

1 如下是代码片断：
2 EXPLAIN SELECT * FROM employees.titles WHERE emp_no - 1='10000'; 
3 +----+-------------+--------+------+---------------+------+---------+------+--------+-------------+ 
4 | id | select_type | table | type | possible_keys | key | key_len | ref | rows | Extra | 
5 +----+-------------+--------+------+---------------+------+---------+------+--------+-------------+ 
6 | 1 | SIMPLE | titles | ALL | NULL | NULL | NULL | NULL | 443308 | Using where | 
7 +----+-------------+--------+------+---------------+------+---------+------+--------+-------------+

　　显然这个查询等价于查询emp_no为10001的函数，可是因为查询条件是一个表达式，MySQL没法为其使用索引。看来MySQL尚未智能到自动优化常量表达式的程度，所以在写查询语句时尽可能避免表达式出如今查询中，而是先手工私下代数运算，转换为无表达式的查询语句。

　　经过一个实际生产环境中的数据存取需求，分析如何设计此存储结构，如何操纵存储的数据，以及如何使操做的成本或代价更低，系统开销最小。同时，让更多初学者明白数据存储的表上索引是如何一个思路组织起来的，但愿起到一个参考模板的价值做用。

　　1.测试用例描述

　　测试用例为B2C领域，一张用于存储用户选购物品而生成的产品订单信息表，不过去掉一些其余字段，以便用于测试，其表中的数据项也不特别描述，字段意思见表：

1 如下是代码片断：
2 SELECT count(DISTINCT(title))/count(*) AS Selectivity FROM employees.titles; 
3 +-------------+ 
4 | Selectivity | 
5 +-------------+ 
6 | 0.0000 | 
7 +-------------+

　　其中，主键信息：PRIMARY KEY(order_id,`goods_id`)，为什么主键索引索引字段的顺序为：order_id,`goods_id`，而不是： `goods_id`, order_id呢?缘由很简单，goods_id在订单信息表中的重复率会比order_id高，也即order_id的筛选率更高，能够减小扫描索引记录个数，从而达到更高的效率，同时，下面即将会列出的SQL也告诉咱们，有部分SQL语句的WHERE字句中只出现order_id字段，为此更加坚决咱们必须把字段：order_id做为联合主键索引的头部，`goods_id`为联合主键索引的尾部。

　　数据存储表设计的小结：

　　设计用于存储数据的表结构，首先要知道有哪些数据项，也即行内常说的数据流，以及各个数据项的属性，好比存储的数据类型、值域范围及长度、数据完整性等要求，从而肯定数据项的属性定义。存储的数据项信息肯定以后，至少进行以下三步分析：

　　● 首先，肯定哪些数据项或组合，能够做为记录的惟一性标志;

　　● 其次，要肯定对数据记录有哪些操做，每一个操做的频率如何，对网站等类型应用，还须要区分前台操做和后台操做，也即分外部用户的操做，仍是内部用户的操做;

　　● 最后，对做为数据记录操做的条件部分的数据项，分析其数据项的筛选率如何，也即数据项不一样值占总数据记录数的比例关心，比例越接近1则是筛选率越好，以及各个值得分布率;

　　综上所述，再让数据修改性操做优先级别高于只读性操做，就能够建立一个知足要求且性能较好的索引组织结构。

　　数据的存取设计,就涉及一块很是重要的知识: 关系数据库的基础知识和关系数据理论的范式。对于范式的知识点，特别解释下，建议学到BCNF范式为止，1NF、2NF、3NF和BCNF之间的差异，各自规避的问题、存在的缺陷都要一清二楚，可是在真实的工做环境中，不要任何存取设计都想向范式靠，用一句佛语准确点表达：空便是色，色便是空。

 

转自：http://database.ctocio.com.cn/257/12120257.shtml

 

多列索引

　　MySQL单列索引是咱们使用MySQL数据库中常常会见到的，MySQL单列索引和组合索引的区别可能有不少人还不是十分的了解，下面就为您分析二者的主要区别，供您参考学习。

　　为了形象地对比二者，再建一个表：

1 CREATE TABLE myIndex ( i_testID INT NOT NULL AUTO_INCREMENT, 
2 vc_Name VARCHAR(50) NOT NULL, 
3 vc_City VARCHAR(50) NOT NULL, i_Age INT NOT NULL, i_SchoolID INT NOT NULL, 
4 PRIMARY KEY (i_testID) );

　　在这 10000 条记录里面 7 上 8 下地分布了 5 条 vc_Name="erquan" 的记录，只不过 city,age,school 的组合各不相同。
　　来看这条query：

1 SELECT i_testID FROM myIndex WHERE vc_Name='erquan' AND vc_City='郑州' AND i_Age=25;

　　首先考虑建MySQL单列索引：
　　在vc_Name列上创建了索引。执行 T-SQL 时，MYSQL 很快将目标锁定在了vc_Name=erquan 的 5 条记录上，取出来放到一中间结果集。在这个结果集里，先排除掉 vc_City 不等于"郑州"的记录，再排除 i_Age 不等于 25 的记录，最后筛选出惟一的符合条件的记录。
　　虽然在 vc_Name 上创建了索引，查询时MYSQL不用扫描整张表，效率有所提升，但离咱们的要求还有必定的距离。一样的，在 vc_City 和 i_Age 分别创建的MySQL单列索引的效率类似。
　　为了进一步榨取 MySQL 的效率，就要考虑创建组合索引。就是将 vc_Name,vc_City，i_Age 建到一个索引里：

1 ALTER TABLE myIndex ADD INDEX name_city_age (vc_Name(10),vc_City,i_Age);

　　建表时，vc_Name 长度为 50，这里为何用 10 呢？由于通常状况下名字的长度不会超过 10，这样会加速索引查询速度，还会减小索引文件的大小，提升 INSERT 的更新速度。
　　执行 T-SQL 时，MySQL 无须扫描任何记录就到找到惟一的记录。
　　确定有人要问了，若是分别在 vc_Name,vc_City，i_Age 上创建单列索引，让该表有 3 个单列索引，查询时和上述的组合索引效率同样吗？大不同，远远低于咱们的组合索引。虽然此时有了三个索引，但 MySQL 只能用到其中的那个它认为彷佛是最有效率的单列索引。
　　创建这样的组合索引，实际上是至关于分别创建了：vc_Name,vc_City,i_Age vc_Name,vc_City vc_Name
　　这样的三个组合索引!为何没有 vc_City，i_Age 等这样的组合索引呢？这是由于 mysql 组合索引“最左前缀”的结果。简单的理解就是只从最左面的开始组合。并非只要包含这三列的查询都会用到该组合索引，下面的几个query会用到：

1 SELECT * FROM myIndex WHREE vc_Name="erquan" AND vc_City="郑州"
2 SELECT * FROM myIndex WHREE vc_Name="erquan"

　　而下面几个则不会用到：

1 SELECT * FROM myIndex WHREE i_Age=20 AND vc_City="郑州" 
2 SELECT * FROM myIndex WHREE vc_City="郑州"

 

使用索引列的查询条件优化： 1.对于多列索引（组合索引），必须有索引中的最左列。
index_a_b_c(a,b,c)这个组合索引能够被使用的条件是a/ab/ac(同单a)/abc

2.对于使用like的查询，后面若是是常量而且只有%号不在第一个字符，索引才可能被使用。
模糊查询遵照最左固定原则，模糊查询的首部不能是%

3.若是对大文本进行搜索，应该使用全文索引。
InnoDB不支持全文索引，MyISAM支持，因此InnoDB表尽可能不要使用like ‘%...%’。

4.若是列名是索引，使用 index_column is null将使用索引。Oracle是不行的。

5.若是mysql估计使用索引比全表扫描更慢，不会使用索引。
能够检查统计当作条件的索引键值是否超过整个表数据的20%，若是超过就不会使用索引。

6.若是使用memory/head表而且where条件中不使用”=”进行索引列，那么不会用到索引。Head表只有在”=”的时候才会使用索引。

7.用or分割开的条件，若是or前的条件中的列有索引，然后面列中没有索引，那么涉及到的索引都不会被用到。

8.若是列是字符串，那么必定要在where条件中把字符串常量的值用引号引发来，不然不能走索引。
mysql默认把输入的常量值进行转换之后才进行检索

9.通过普通运算或函数运算后的索引字段不能使用索引

10.不等于操做不能使用索引，<>、not in等

11.Order by 优化：某些状况下，mysql可使用一个索引知足order by,而不须要额外的排序。Where条件与order by 使用相同的索引，而且order by的顺序和索引顺序相同，而且order by的字段都是升序或者都是降序。
SELECT * FROM t1 ORDER BY key_part1,key_part2,... ;
SELECT * FROM t1 WHERE key_part1=1 ORDER BY key_part1 DESC, key_part2
DESC;
SELECT * FROM t1 ORDER BY key_part1 DESC, key_part2 DESC;
可是如下状况不使用索引：
SELECT * FROM t1 ORDER BY key_part1 DESC, key_part2 ASC ；
--order by 的字段混合 ASC 和 DESC
SELECT * FROM t1 WHERE key2=constant ORDER BY key1 ；
-- 用于查询行的关键字与 ORDER BY 中所使用的不相同
SELECT * FROM t1 ORDER BY key1, key2 ；
-- 对不一样的关键字使用 ORDER BY