【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 |
+----+-------------+--------+------+---------------+------+---------+------+--------+-------------+

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

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

 以下是代码片段：
 EXPLAIN SELECT * FROM employees.titles WHERE emp_no='' AND title LIKE 'Senior%';
 view sourceprint?
 +----+-------------+--------+-------+---------------+---------+---------+------+------+-------------+
 | id | select_type | table | type | possible_keys | key | key_len | ref | rows | Extra |
 +----+-------------+--------+-------+---------------+---------+---------+------+------+-------------+
 | 1 | SIMPLE | titles | range | PRIMARY | PRIMARY | 56 | NULL | 1 | Using where |
 +----+-------------+--------+-------+---------------+---------+---------+------+------+-------------+

　　此时可以用到索引，但是如果通配符不是只出现在末尾，则无法使用索引，例如like '%x%'或‘%x’都无法使用到索引。

　　情况六：范围查询。

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

　　范围列可以用到索引(必须是最左前缀)，但是范围列后面的列无法用到索引。同时，索引最多用于一个范围列，因此如果查询条件中有两个范围列则无法全用到索引。

 以下是代码片段：
 EXPLAIN SELECT * FROM employees.titles
 WHERE emp_no<''
 AND title='Senior Engineer'
 AND from_date BETWEEN '1986-01-01' AND '1986-12-31';
 +----+-------------+--------+-------+---------------+---------+---------+------+------+-------------+
 | id | select_type | table | type | possible_keys | key | key_len | ref | rows | Extra |
 +----+-------------+--------+-------+---------------+---------+---------+------+------+-------------+
 | 1 | SIMPLE | titles | range | PRIMARY | PRIMARY | 4 | NULL | 16 | Using where |
 +----+-------------+--------+-------+---------------+---------+---------+------+------+-------------+

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

 以下是代码片段：
 EXPLAIN SELECT * FROM employees.titles
 WHERE emp_no BETWEEN '' AND ''
 AND title='Senior Engineer'
 AND from_date BETWEEN '1986-01-01' AND '1986-12-31';
 +----+-------------+--------+-------+---------------+---------+---------+------+------+-------------+
 | id | select_type | table | type | possible_keys | key | key_len | ref | rows | Extra |
 +----+-------------+--------+-------+---------------+---------+---------+------+------+-------------+
 | 1 | SIMPLE | titles | range | PRIMARY | PRIMARY | 59 | NULL | 16 | Using where |
 +----+-------------+--------+-------+---------------+---------+---------+------+------+-------------+

　　看起来是用了两个范围查询，但作用于emp_no上的“BETWEEN”实际上相当于“IN”，也就是说emp_no实际是多值精确匹配。可以看到这个查询用到了索引全部三个列。因此在MySQL中要谨慎地区分多值匹配和范围匹配，否则会对MySQL的行为产生困惑。

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

　　虽然这个查询和情况五中功能相同，但是由于使用了函数left，则无法为title列应用索引，而情况五中用LIKE则可以。再如：

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

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

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

　　1.测试用例描述

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

 以下是代码片段：
 SELECT count(DISTINCT(title))/count(*) AS Selectivity FROM employees.titles;
 +-------------+
 | Selectivity |
 +-------------+
 | 0.0000 |
 +-------------+

　　其中，主键信息：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单列索引和组合索引的区别可能有很多人还不是十分的了解，下面就为您分析两者的主要区别，供您参考学习。

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

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

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

 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 建到一个索引里：

 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会用到：

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

　　而下面几个则不会用到：

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

使用索引列的查询条件优化：

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

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

.如果对大文本进行搜索，应该使用全文索引。
InnoDB不支持全文索引，MyISAM支持，所以InnoDB表尽量不要使用like ‘%...%’。

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

.如果mysql估计使用索引比全表扫描更慢，不会使用索引。
可以检查统计当做条件的索引键值是否超过整个表数据的20%，如果超过就不会使用索引。

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

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

.如果列是字符串，那么一定要在where条件中把字符串常量的值用引号引起来，否则不能走索引。
mysql默认把输入的常量值进行转换以后才进行检索

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

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

.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= 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