1. 索引建立的原则 用于索引的最好的备选数据列是那些出现在WHERE子句、join子句、ORDER BY或GROUP BY子句中的列。 仅仅出现在SELECT关键字后面的输出数据列列表中的数据列不是很好的备选列 SELECT col_a <- 不是备选列 FROM tbl1 LEFT JOIN tbl2 ON tbl1.col_b = tbl2.col_c <- 备选列 WHERE col_d = expr; <- 备选列 当然，显示的数据列与WHERE子句中使用的数据列也可能相同。 我们的观点是输出列表中的数据列本质上不是用于索引的很好的备选列。 2. 复合索引的建立以及最左前缀原则 索引字符串值的前缀（prefixe）。如果你需要索引一个字符串数据列，那么最好在任何适当的情况下都应该指定前缀长度。 例如，如果有CHAR(200)数据列，如果前面10个或20个字符都不同，就不要索引整个数据列。 索引前面10个或20个字符会节省大量的空间 你可以索引CHAR、VARCHAR、BINARY、VARBINARY、BLOB和TEXT数据列的前缀。 假设你在表的state、city和zip数据列上建立了复合索引。索引中的数据行按照state/city/zip次序排列， 因此它们也会自动地按照state/city和state次序排列。这意味着，即使你在查询中只指定了state值， 或者指定state和city值，MySQL也可以使用这个索引。因此，这个索引可以被用于搜索如下所示的数据列组合： state, city, zip state, city state MySQL不能利用这个索引来搜索没有包含在最左前缀的内容。例如，如果你按照city或zip来搜索， 就不会使用到这个索引。如果你搜索给定的state和具体的ZIP代码（索引的1和3列）， 该索引也是不能用于这种组合值的，尽管MySQL可以利用索引来查找匹配的state从而缩小搜索的范围。 如果你考虑给已经索引过的表添加索引，那么就要考虑你将增加的索引是否是已有的多列索引的最左前缀。 如果是这样的，不用增加索引，因为已经有了(例如，如果你在state、city和zip上建立了索引，那么没有必要再增加state的索引)。 3. 实例分析 通过实例理解单列索引、多列索引以及最左前缀原则 实例：现在我们想查出满足以下条件的用户id： mysql>SELECT ｀uid｀ FROM people WHERE lname｀='Liu' AND ｀fname｀='Zhiqun' AND ｀age｀=26 因为我们不想扫描整表，故考虑用索引。 单列索引： ALTER TABLE people ADD INDEX lname (lname); 将lname列建索引，这样就把范围限制在lname='Liu'的结果集1上，之后扫描结果集1，产生满足fname='Zhiqun'的结果集2，再扫描结果集2，找到 age=26的结果集3，即最终结果。 由于建立了lname列的索引，与执行表的完全扫描相比，效率提高了很多，但我们要求扫描的记录数量仍旧远远超过了实际所需 要的。虽然我们可以删除lname列上的索引，再创建fname或者age 列的索引，但是，不论在哪个列上创建索引搜索效率仍旧相似。 多列索引： ALTER TABLE people ADD INDEX lname_fname_age (lame,fname,age); 为了提高搜索效率，我们需要考虑运用多列索引,由于索引文件以B－Tree格式保存，所以我们不用扫描任何记录，即可得到最终结果。 注：在mysql中执行查询时，只能使用一个索引，如果我们在lname,fname,age上分别建索引,执行查询时，只能使用一个索引，mysql会选择一个最严格(获得结果集记录数最少)的索引。 3.最左前缀：顾名思义，就是最左优先，上例中我们创建了lname_fname_age多列索引,相当于创建了(lname)单列索引，(lname,fname)组合索引以及(lname,fname,age)组合索引。 注：在创建多列索引时，要根据业务需求，where子句中使用最频繁的一列放在最左边。
CREATE TABLE `student` ( `id` int(11) NOT NULL AUTO_INCREMENT, `name` varchar(255) DEFAULT NULL, `cid` int(11) DEFAULT NULL, PRIMARY KEY (`id`), KEY `name_cid_INX` (`name`,`cid`), KEY `name_INX` (`name`) ) ENGINE=InnoDB AUTO_INCREMENT=8 DEFAULT CHARSET=utf8 复制代码 执行1: EXPLAIN SELECT * FROM student WHERE name='小红'; 执行2: EXPLAIN SELECT * FROM student WHERE cid=1; EXPLAIN SELECT * FROM student WHERE cid=1 AND name='小红'; 为什么还能匹配索引？ 你的疑问是：sql查询用到索引的条件是必须要遵守最左前缀原则，为什么上面两个查询还能用到索引？ --------------------------------------------------------------------------------------------------------------------------- 讲上面问题之前，我先补充一些知识，因为我觉得你对索引理解是狭隘的： 上述你的两个查询的explain结果中显示用到索引的情况类型是不一样的。,可观察explain结果中的type字段。你的查询中分别是： 1. type: index 2. type: ref 解释： index：这种类型表示是mysql会对整个该索引进行扫描。 要想用到这种类型的索引，对这个索引并无特别要求，只要是索引，或者某个复合索引的一部分，mysql都可能会采用index类型的方式扫描。 但是呢，缺点是效率不高，mysql会从索引中的第一个数据一个个的查找到最后一个数据，直到找到符合判断条件的某个索引。 所以：对于你的第一条语句： EXPLAIN SELECT * FROM student WHERE cid=1; 判断条件是cid=1,而cid是(name,cid)复合索引的一部分，没有问题，可以进行index类型的索引扫描方式。explain显示结果使用到了索引，是index类型的方式。 --------------------------------------------------------------------------------------------------------------------------- ref：这种类型表示mysql会根据特定的算法快速查找到某个符合条件的索引，而不是会对索引中每一个数据都进行一 一的扫描判断，也就是所谓你平常理解的使用索引查询会更快的取出数据。 而要想实现这种查找，索引却是有要求的，要实现这种能快速查找的算法，索引就要满足特定的数据结构。 简单说，也就是索引字段的数据必须是有序的，才能实现这种类型的查找，才能利用到索引。 有些了解的人可能会问，索引不都是一个有序排列的数据结构么。不过答案说的还不够完善，那只是针对单个索引，而复合索引的情况有些同学可能就不太了解了。 下面就说下复合索引： 以该表的(name,cid)复合索引为例,它内部结构简单说就是下面这样排列的： mysql创建复合索引的规则是首先会对复合索引的最左边的，也就是第一个name字段的数据进行排序，在第一个字段的排序基础上，然后再对后面第二个的cid字段进行排序。 其实就相当于实现了类似 order by name cid这样一种排序规则。 所以：第一个name字段是绝对有序的，而第二字段就是无序的了。 所以通常情况下，直接使用第二个cid字段进行条件判断是用不到索引的，当然，可能会出现上面的使用index类型的索引。 这就是所谓的mysql为什么要强调最左前缀原则的原因。 那么什么时候才能用到呢? 当然是cid字段的索引数据也是有序的情况下才能使用咯，什么时候才是有序的呢？ 观察可知，当然是在name字段是等值匹配的情况下，cid才是有序的。 发现没有，观察两个name名字为 c 的cid字段是不是有序的呢。从上往下分别是4 5。 这也就是mysql索引规则中要求复合索引要想使用第二个索引，必须先使用第一个索引的原因。（而且第一个索引必须是等值匹配）。 --------------------------------------------------------------------------------------------------------------------------- 所以对于你的这条sql查询： EXPLAIN SELECT * FROM student WHERE cid=1 AND name='小红'; 没有错，而且复合索引中的两个索引字段都能很好的利用到了！因为语句中最左面的name字段进行了等值匹配，所以cid是有序的，也可以利用到索引了。 你可能会问： 我建的索引是(name,cid)。 而我查询的语句是cid=1 AND name='小红'; 我是先查询cid，再查询name的，不是先从最左面查的呀？ 好吧，我再解释一下这个问题：首先可以肯定的是把条件判断反过来变成这样 name='小红' and cid=1; 最后所查询的结果是一样的。 那么问题产生了？既然结果是一样的，到底以何种顺序的查询方式最好呢？ 所以 而此时那就是我们的mysql查询优化器该登场了，mysql查询优化器会判断纠正这条sql语句该以什么样的顺序执行效率最高，最后才生成真正的执行计划。 所以，当然是我们能尽量的利用到索引时的查询顺序效率最高咯，所以mysql查询优化器会最终以这种顺序进行查询执行。