mysql 多重索引_where条件中出现了（不等于/多重范围）就一定不走索引了吗

今天朋友抛了一个群里的讨论给我，如下图

这题我选择了A,B，因为我认为A和B都不满足最左；最后朋友实际建表的测试结果如下(也就是说答案应该是A,B,D)

按理说不等于不走索引应该是SQL优化的常识了，为什么我在选择的时候排除了D呢？因为2个月前我遇到了这样一个语句

SELECT MAX(id)

FROM a

WHERE user_id != '18'

AND '2019-02-13 00:00:00' >= create_time

GROUP BY user_id;

因为这个语句的关系，我一度认为在5.7.25版本里不等于也已经开始智能的走索引了；经过这个选择题，决定仔细探索一下MySQL的不等于

对原语句进行不同的改写

备注：

①索引idx_uid_ct为user_id和create_time的联合索引idx_uid_ct(user_id,create_time)

②后面为了测试，特意删除了idx_ct(create_time)

③id为表的主键列

eg1.去除group by的影响，type为range，覆盖索引

eg2.去除max函数，type为range，覆盖索引

eg3.查询项改为create_time、user_id、id中的任意1到3个，type为range，覆盖索引

eg4.查询项改为*或者是索引列(user_id，create_time，id)之外的任意值，索引前导列存在不等于，不走索引

eg5.查询项改为*或者是索引列(user_id，create_time，id)之外的任意值，索引的非前导列存在不等于，走索引，extra为ICP

eg6.查询项改为create_time或者user_id，where条件改为只有非前导列create_time，不满足idx_uid_ct最左匹配规则，type为index，覆盖索引

eg7.查询项改为索引列(user_id，create_time，id)之外的任意值，where条件将user_id的不等于改为等于，create_time条件不变，type为range，Extra为ICP

eg8.查询项改为索引列(user_id，create_time，id)之外的任意值，where条件将user_id的不等于改为大于或者小于，create_time条件不变，是否走索引需要优化器进行判断

eg9.查询项改为索引列(user_id，create_time，id)之中的任意1-3个值，where条件将user_id的不等于改为大于或者小于，create_time条件不变，type为range，覆盖索引

结论

①对比上面的9个eg可以看出，当查询列位于主键或者索引列范围内的时候(或者像原语句那样是主键/索引列的分组函数)，整个语句会直接走覆盖索引，这种情况下无论where条件里有没有不等于都不会有影响

②参考eg4可知查询列在索引列或主键列的范围之外，索引前导列存在不等于，不走索引

③参考eg5可知，查询列在索引列或主键列的范围之外，索引非前导列存在不等于，仍然走索引，此时需要回表，因此extra为ICP。

④对比eg5和eg7，两者的执行计划中的extra均为ICP，但key_len和type不同；eg5的非前导列在where条件中存在不等于，因此联合索引中的非前导列create_time并没有被利用到，所以key_len只有99；eg7的非前导列条件where条件中是一个范围，由于是where条件中的第一个范围，因此这个范围可以走索引，所以key_len为105；eg5和eg7之所以都是ICP是因为查询列user_name需要回表

⑤参考eg9，当满足覆盖索引条件的时候，即使在where条件中有双范围，第一个范围走了索引，第二个范围没有走索引(key_len为99)

⑥参考eg8，不满足覆盖索引条件时，where条件中只有第一个范围能被索引利用到，是否走索引优化器自身会做权衡，当取值量太大时索引反而不如全表

⑦eg6是一个我不能理解的eg，满足覆盖索引条件时，即使where条件不满足索引的最左规则，语句仍然走了索引只不过type为极为低效的index(全索引扫描)，extra显示此时仍然是覆盖索引；有趣的是这里的key_len竟然是105，而实际上where条件里面只有create_time(该列的key_len应该只有6才对)

综上可以知道在覆盖索引的情况下，不等于仍然会走索引(无论这个不等于是否存在于前导列的where条件上)，而多重范围的第一个范围会走索引，而后面的多重范围则不会走索引，只是用来作为过滤条件使用；

在非覆盖的索引下，不等于不会走索引(如果是前导列存在不等于，这个索引直接不会走；如果是非前导列存在不等于，这个索引有可能被用到，但即使索引被用到，索引中这个存在不等于的列也不会被用到)，而多重范围的后几层范围肯定不会被用到，第一层范围是否会用到需要优化器进行权衡

补充

SELECT sum( amount ) FROM t

WHERE

STATUS = 'success'

AND partner_id != 'aaa' AND partner_id != 'bbb' AND partner_id != 'ccc'

AND date_format( update_time, '%y-%m-%d' ) = date_format( now( ), '%y-%m-%d' );

建立测试索引

idx_0(status,partner_id,update_time,amount)

idx_1(status,partner_id,amount)

①在采用idx_1时，索引只走了idx_1中的status部分，这时候存在不等于条件的partner_id只是起到了过滤的作用(这个过滤作用使得该语句执行速度提升10倍)

②在采用idx_0时，索引走了idx_0中的status和partner_id部分，这时候因为已经是覆盖查询了，根据前面的实验可以知道不等于也走了索引，但是最末端的update_time仍然没有走索引，而只是起到了过滤的作用(这个过滤作用使得该语句在之前提升10倍的基础上再提升了10倍)

结论

在覆盖索引的情况下，不等于会走索引，多重范围不会走索引，函数也不会走索引