我们可以通过SHOW STATUS LIKE 'Handler_read%';查看索引的使用情况：
● Handler_read_key：如果索引正在工作，Handler_read_key的值将很高。
● Handler_read_rnd_next：数据文件中读取下一行的请求数，如果正在进行大量的表扫描，值将较高，则说明索引利用不理想。
前导模糊查询不能命中索引：
数据类型出现隐式转换的时候不会命中索引，特别是当列类型是字符串，一定要将字符常量值用引号引起来
复合索引的情况下，查询条件不包含索引列最左边部分（不满足最左原则），不会命中符合索引
最左原则并不是说是查询条件的顺序,而是查询条件中是否包含索引最左列字段
union、in、or都能够命中索引，建议使用in
用or分割开的条件，如果or前的条件中列有索引，而后面的列中没有索引，那么涉及到的索引都不会被用到
● 负向条件查询不能使用索引，可以优化为in查询。
负向条件有：!=、<>、not in、not exists、not like等。
可以优化为in查询，但是前提是区分度要高，返回数据的比例在30%以内：
范围条件查询可以命中索引。范围条件有：<、<=、>、>=、between等
范围列可以用到索引（联合索引必须是最左前缀），但是范围列后面的列无法用到索引，索引最多用于一个范围列，如果查询条件中有两个范围列则无法全用到索引：
比如：EXPLAIN SELECT * FROM user WHERE status>5 AND age<24;
如果是范围查询和等值查询同时存在，优先匹配等值查询列的索引：
数据库执行计算不会命中索引：SELECT * FROM user WHERE age+1>24;
● 建立索引的列，不允许为null。
● IS NULL可以命中索引
● IS NOT NULL不能命中索引：
● 更新十分频繁的字段上不宜建立索引：因为更新操作会变更B+树，重建索引。这个过程是十分消耗数据库性能的。
● 区分度不大的字段上不宜建立索引：类似于性别这种区分度不大的字段，建立索引的意义不大。因为不能有效过滤数据，性能和全表扫描相当。另外返回数据的比例在30%以外的情况下，优化器不会选择使用索引。
● 业务上具有唯一特性的字段，即使是多个字段的组合，也必须建成唯一索引。虽然唯一索引会影响insert速度，但是对于查询的速度提升是非常明显的。另外，即使在应用层做了非常完善的校验控制，只要没有唯一索引，在并发的情况下，依然有脏数据产生。
● 多表关联时，要保证关联字段上一定有索引。
● 创建索引时避免以下错误观念：索引越多越好，认为一个查询就需要建一个索引；宁缺勿滥，认为索引会消耗空间、严重拖慢更新和新增速度；抵制唯一索引，认为业务的唯一性一律需要在应用层通过“先查后插”方式解决；过早优化，在不了解系统的情况下就开始优化。
网友评论