共计 1076 个字符，预计需要花费 3 分钟才能阅读完成。
这篇文章主要介绍“mysql in 慢查询如何优化”，在日常操作中，相信很多人在 mysql in 慢查询如何优化问题上存在疑惑，丸趣 TV 小编查阅了各式资料，整理出简单好用的操作方法，希望对大家解答”mysql in 慢查询如何优化”的疑惑有所帮助！接下来，请跟着丸趣 TV 小编一起来学习吧！
第一步、分析 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，赤裸裸的没走索引啊。
第三步、检查两个关联字段的字段类型、长度和字符类型是否一致
当比较字段类型和字段长度发现完全一致，短暂的郁闷之后，发现了新的线索——
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 慢查询如何优化”的学习就结束了，希望能够解决大家的疑惑。理论与实践的搭配能更好的帮助大家学习，快去试试吧！若想继续学习更多相关知识，请继续关注丸趣 TV 网站，丸趣 TV 小编会继续努力为大家带来更多实用的文章！
