SQL优化(2)-索引使用、设计规则
索引使用规则：
- 全值匹配，索引中所有列都指定具体值。该情况下，索引生效，执行效率高。
- 最左前缀法则：如果索引了多列，要遵守最左前缀法则。指的是查询从索引的最左前列开始，并且不跳过索引中的列。匹配最左前缀法则，走索引。违反最左前缀法则，索引失效。如果符合最左法则，但是出现跳跃某一列，只有最左列索引生效。
- 范围查询右侧列，不使用索引
- 在索引上做运算操作，索引失效
- 字符串不加单引号，索引失效
- 使用or分隔开的条件，如果or前面使用索引列、后面没有索引列，那么涉及的索引都不会被用到
- 以%开头的Like模糊查询，索引失效。解决方案：通过覆盖索引
- 如果MySQL评估使用索引比全表更慢，则不使用索引
- is NULL，is NOT有时索引失效。实验中： NULL查询条件中IS NULL，当命中结果数量小于40%的时候，会走索引。查询条件中的IS NOT NULL,命中结果数小于30%的时候，会走索引。
- in，not in有时索引失效。
- 尽量使用覆盖索引，避免select *
索引设计原则：
- 对查询频次较高，且数据量比较大的表建立索引。
- 索引字段的选择，最佳候选列应当从where子句的条件中提取，如果where子句中的组合比较多，那么应当挑选最常用、过滤效果最好的列的组合。
- 使用唯一索引，区分度越高，使用索引的效率越高。
- 索引可以有效的提升查询数据的效率，但索引数量不是多多益善，索引越多，维护索引的代价自然也就水涨船高。对于插入、更新、删除等DML操作比较频繁的表来说，索引过多，会引入相当高的维护代价，降低DML操作的效率，增加相应操作的时间消耗。另外索引过多的话，MySQL也会犯选择困难病，虽然最终仍然会找到一个可用的索引，但无疑提高了选择的代价。使用短索引，索引创建之后也是使用硬盘来存储的，因此提升索引访问的I/O效率，也可以提升总体的访问效率。假如构成索引的字段总长度比较短，那么在给定大小的存储块内可以存储更多的索引值，相应的可以有效的提升MySQL访问索引的I/O效率。
- 利用最左前缀，N个列组合而成的组合索引，那么相当于是创建了N个索引，如果查询时where子句中使用了组成该索引的前几个字段，那么这条查询SQL可以利用组合索引来提升查询效率。
