mysql not in 索引

为解决cpu100问题, 首先查看了阿里云cpu与其他参数对比情况, 查看慢sql, 表结构相关索引都已经创建好了, 虽然存在问题, 但没有太大影响, 优化代码时发现语句中很多处都使用了not in (), 记得之前看过not in 与 != , <> , or 等等都会使索引失效, 因此试了一下将not in 改成in , 将数据直接填充到in () 中对比执行时间(在java业务逻辑层通过not in 数据获取in 中数据), 刚开始随意填入几条数据发现效果非常好, 从8秒缩减到0.15s, 用实际数据填充对比时发现并没有那么乐观, 多个not in 都转换为in 时, 执行时间延长了, 用EXPLAIN 查看语句不断的调试对比, 在这个过程当中发现了好多有趣的东西, not in 也会用到索引, 经过多次验证调试发现会因为显示的字段列的多少/类型, 数据量大小, 数据量占比不同从而影响索引的命中, 而多次验证的结果中符合索引基本不会命中not in 的数据字段, 在这其中还发现另一个非常有趣是现象, EXPLAIN 查看时, key中显示的索引并不在possible_keys当中, 查找了一下, 以相同字段开头的索引在查询过程中起作用的索引字段相同时, 会出现覆盖现象. 再有一个就是mysql 会将=字段排列在前, 其他相同级别例如多个 in () 会进行自主调整, 前后顺序并未影响复合索引的使用,都会命中, 这一点与我们所知的左优先顺序有点不一样
上述发现的有趣现象查找了一些相关资料显示mysql5.6是里程碑式的进步, 5.7在5.6的基础上同样有所提升, 在5.6版本之后 not in , != 等等这些也可以命中索引了, mysql 会进行自主优化, 总之哪个索引能过滤掉更多数据会使用那个索引, in () 中如果包含数据量过多当mysql认为不如全表扫描效率高时同样不会命中索引, 一句话: 谁行谁上不行就pass掉!
上述内容大多是自己编写sql语句进行调整测试后得到的结论, 如果有不对的地方欢迎指出, 共同进步, 加油

吐槽一下, 在处理服务器中的一些项目cpu100波动图与慢日志,看了看语句优化一下还是可以的,结合项目后发现就是个坑, 项目使用使用中sql语句where条件20多个, 优化的时候, 联合索引根本起不到啥作用, 不同请求参数sql也不一样, 洋洋洒洒将近200行的一条综合sql语句啊, 多表关联等等, 更过分的是几乎相同的sql语句被20个接口调用,部分接口底层调用的是同一个方法, 上层业务繁杂, 不敢动啊, 拆分sql, java分担的空间换时间搞不了, 没办法只能硬着头皮搞纯sql优化试一试. 接手外包项目就是在折磨自己啊, 要是再有点代码强迫症,疯了, 只能不断的告诫自己, 管不到别人,管好咱自己, 不管啥时候自己绝对不要这样的方式写业务代码和sql语句, 坑人坑己! 把非常复杂的业务逻辑用一条sql语句多关联几张表就编写出来, 我只能说很厉害, 但不管是后期维护优化还是业务扩展都非常麻烦甚至尾大不掉, 这样的复杂业务sql语句编写完如果有错误排查太难, 过个一个月自己还能想起来怎么改怎么写不?!