1 联合索引最左前缀法则
create index n_a_p_index on person(name,age,phone)如果索引了多列（联合索引），要遵守最左前缀法则。最左前缀法则指的是查询从索引的最左列开始，并且不跳过索引中的列。
explain select * from person where name = '小明' and age = 11 and phone = '11'使用了索引n_a_p_index，索引长度为143
explain select * from person where name = '小明' and age = 11使用了索引n_a_p_index，索引长度也为44,这说明phone上的索引长度为99
explain select * from person where name = '小明'使用了索引n_a_p_index，索引长度为39，这是说明name上的索引长度为39，age上的索引长度为5
explain select * from person where name = '小明' and phone = '11'使用了索引n_a_p_index，索引长度也为39,这说明phone索引失效了，这是因为我们跳过了age
explain select * from person where age = 11 and phone = '11'
注意 name，age和phone位置摆放不影响上面的结果
结论：只有最左索引在，索引就会生效，单如果跳跃某一列，后面的索引就不是有序的，所以会失效。
2 联合索引范围查询
联合索引中，出现范围查询（>，<），范围查询右侧的列索失效
explain select * from person where name = '枫翎一中' and age > 22 and phone = '11111'
如果我们想要phone上的索引生效，我们可以使用>=，如下。注意，这种优化有时可能是无效的，因为mysql内部有他自己的索引评估优化。
explain select * from person where name = '枫翎一中' and age >= 22 and phone = '11111'
3 不在索引列上做任何操作（计算、函数、（自动or手动）类型转换），会导致索引失效而转向全表扫描
因为如果在索引列上进行运算操作，那么其计算的值和不是b+tree中节点的值，不能进行查询
explain select * from person where substring(home,2) = '海'
4 字符串类型索引使用时，不加引号，索引将失效
字符串类型索引使用时，不加引号进行查找时，mysql底层会把字段进行string计算
create index home_index on person(home)先加引号
explain select * from person where home = '11'
不加引号
explain select * from person where home = 11
5 头部模糊匹配，索引失效，会变成全表扫描操作
like KK%相当于=常量，%KK和%KK% 相当于范围
索引使用时，如果仅仅是尾部模糊匹配，索引不会失效。
explain select * from person where home like '上%'
如果是头部模糊匹配，索引失效。
explain select * from person where home like '%上'
下面在来个思考题，下面age和phone会走索引么？
create index n_a_p_index on person (name, age, phone);
explain select * from person where name like '小明%' and age = 11 and phone = '1'
会？那这是为什么呢？正常情况按照最左前缀原则，这种情况只会走name字段索引，因为根据name字段过滤完，得到的索引行里的age和 phone是无序的，无法很好的利用索引。
在MySQL5.6之前的版本，这个查询只能在联合索引里匹配到名字是 ‘小明’ 开头的索引，然后拿这些索引对应的主键逐个回表，到主键索 引上找出相应的记录，再比对age和phone这两个字段的值是否符合。
MySQL 5.6引入了索引下推优化，可以在索引遍历过程中，对索引中包含的所有字段先做判断，过滤掉不符合条件的记录之后再回表，可 以有效的减少回表次数。使用了索引下推优化后，上面那个查询在联合索引里匹配到名字是 ‘小明’ 开头的索引之后，同时还会在索引里过 滤age和phone这两个字段，拿着过滤完剩下的索引对应的主键id再回表查整行数据。
索引下推会减少回表次数，对于innodb引擎的表索引下推只能用于二级索引，innodb的主键索引（聚簇索引）树叶子节点上保存的是全 行数据，所以这个时候索引下推并不会起到减少查询全行数据的效果。
为什么范围查找Mysql没有用索引下推优化？ 我猜应该是Mysql认为范围查找过滤的结果集过大，like KK% 在绝大多数情况来看，过滤后的结果集比较小，所以这里Mysql选择给 like KK% 用了索引下推优化，当然这也不是绝对的，有时like KK% 也不一定就会走索引下推。
6 or连接
home和school上有索引，phone没有
or连接的条件，如果or一条件中的列有索引，而后面的列中没有索引，那么涉及的索引都不会被用到。
explain select * from person where phone = '1111' or home = '上海'
explain select * from person where home = '上海' or phone = '1111'
除非都2个条件列都有索引
explain select * from person where school = '北京大学' or home = '上海'
7 MySQ索引评估
如果MySQ评估使用索引比全表更慢，则不使用索引。如下
explain select * from person where home is not null因为表中home都有值
explain select * from person where home is null
注意如果我把home值都变为null，上面的结果会相反，这就是MySQ的索引评估
索引设计原则
1.针对于数据量较大，且查询比较频繁的表建立索引。
2.针对于常作为查询条件（where）、排序（order by）、分组（group by）操作的字段建立索引。
3.尽量选择区分度高的列作为索引，尽量建立唯一索引，区分度越高，使用索引的效率越高。
4.如果是字符串类型的字段，字段的长度较长，可以针对于字段的特点，建立前缀索引。
5.尽量使用联合索引，减少单列索引，查询时，联合索引很多时候可以覆盖索引，节省存储空间，避免回表，提高查询效率。
6.要控制索引的数量，索引并不是多多益善，索引越多，维护索引结构的代价也就越大，会影响增删改的效率。
7.如果索引列不能存储NULL值，请在创建表时使用NOT NU儿L约束它。当优化器知道每列是否包含NU儿L值时，它可以更好地确定哪个
索引最有效地用于查询。
