最左前缀原则
B+树这种索引结构可以利用索引的"最左前缀"来定位记录。
使用上文中的[name-age]联合索引分析
索引项是按照索引定义里面出现的字段排序的。当需要查询所有姓名是“张三”的人时，可以快速定位到ID4，然后向后遍历得到所有需要的结果。如果是要查所有第一个名字里是“张”的人，也可以用上这个索引，查到第一个符合条件的记录是ID3，然后向后遍历，直到不满足条件为止。
不只是索引的全部定义，只要满足最左前缀，就可以利用索引来加速检索。这个前缀可以是联合索引的最左N个字段，也可以是字符串索引的最左M个字符。
思考一个比较经典的问题：在建立联合索引的时候，如果安排索引内的字段顺序？
这里的评估标准是索引的复用能力。因为可以支持最左前缀，当已经有了(a,b)这个联合索引后，一般就不需要单独在a上建立索引了。因此，第一原则是，如果通过调整顺序可以少维护一个索引，那么这个顺序就是优先考虑要采用的。
如果又有联合查询，又有基于a,b各自的查询呢？查询条件里只有b的语句，是无法使用(a,b)这个联合索引的，这时候需要同时维护(a,b)和(b)这两个索引。这时候要考虑的原则就是空间了，比如上面的例子里，name字段要比age字段大，就更建议创建(name,age)的联合索引和(age)的单字段索引。
索引下推
在最左前缀原则里，最左前缀可以用于在索引中定位记录。那那些不符合最左前缀的部分会怎么样呢？
还是以市民表的联合索引(name,age)为例。现在的需求是：检索出表里“第一个名字是张，而且年龄是10岁的所有男孩”
select * from tuser where name like '张%' and age=10 and ismale=1;
这个语句在搜索索引树的时候，只能用“张”找到第一个满足条件的记录ID3.然后判断其他条件是否满足。
在MySQL5.6之前，只能从ID3开始一个个回表，到主键索引上找出数据行，再对比字段值。
在MySQL5.6以后，引入了索引下推优化，在索引遍历过程中，对索引中包含的字段先做判断，直接过滤掉不满足条件的记录，减少回表次数。
每个虚线箭头表示回表一次。第二种的区别是InnoDB在(name,age)索引内部就判断了age是否等于10，对不等于10的记录，直接判断并跳过。
