遇事不慌，先记录：mysql in慢查询优化

本篇文章给大家带来了关于mysql慢查询优化的问题， 我会一步步带大家分析SQL、检查并优化，下面一起来看一下，希望对大家有帮助。

记一次mysql慢查询优化——生产环境待办列表现场演示5~6s才加载出来结果；顿时，产品经理的脸挂不住了，作为多年经验的老开发，心想完犊子，脸啪啪滴。

不过，秉着多年的江湖经验，遇事不慌，拍个照先。

推荐学习：《MySQL视频教程》

第一步、分析SQL

 ***from event i 
 left join project p on i.project_id = p.project_code 
 left join dict d on i.type_id = d.id 
 left join record re on re.incident_id = i.id
 left join type it on it.id = i.type_id 
 where i.version_flag = 0 and i.flow_id in (大量条件)***复制代码

当flow_id in接入大量条件，sql直接变慢，由之前的80ms到5.8秒，另外此处，关联表较多。

第二步、检查索引，执行explain

当我们检查索引发现re.incident_id和i.flow_id并没有走索引，so，大喜，问题找到了，建索引；然而执行SQL，发现并卵！机智如我，直接打开explain，发现record的type为all，赤裸裸的没走索引啊。

why?why?

第三步、检查两个关联字段的字段类型、长度和字符类型是否一致

当比较字段类型和字段长度发现完全一致，短暂的郁闷之后，发现了新的线索——

event表的id的字符类型为：

record表的incident_id的字符类型为：

果断统一使用utf8mb4与项目组保持统一；再次explain，耗时瞬间低至1秒之内，手工。

第四步、强制使用索引操作

mysql在一个表如果索引基数过小的情况下默认会走全文搜索，所以对于表业务量过大，但是索引字段基本上为同一数据或null的情况 还是需要在sql中写死强制索引;在sql中使用强制索引解决办法 left join 后添加 force index(alarm_id)——

第五步、IN通常是走索引的

只有当IN后面的数据在数据表中超过30% 的匹配时是全表扫描，不走索引，因此IN走不走索引和后面的数据量有关系。 in大量数据可以使用left join来处理。

以上就是遇事不慌，先记录：mysql in慢查询优化的详细内容，更多请关注其它相关文章！