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

索引的使用

示例数据库

为了讨论索引策略，需要一个数据量不算小的数据库作为示例。本文选用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表的主索引为，还有一个辅助索引。为了避免多个索引使事情变复杂(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 | |

+----+-------------+--------+------+---------------+---------+---------+-------+------+-------+

当查询条件精确匹配索引的左边连续一个或几个列时，如或，所以可以被用到，但是只能用到一部分，即条件所组成的最左前缀。上面的查询从分析结果看用到了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 之间的“坑”填上。

首先我们看下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 viewsourceprint?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

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 * FROMemployees.titles3 WHERE emp_no

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 * FROMemployees.titles3 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 FROMemployees.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 NULLAUTO_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)/abc2.对于使用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=1ORDER 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