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

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

在生产环境中，查询速度的优化是十分重要的，如果查询速度过慢，会对业务流程产生极大的影响。本文将介绍一次对mysql慢查询进行优化的过程。

该项目的待办列表在现场演示时加载需要5~6秒的时间，导致产品经理的脸挂不住，作为多年经验的老开发也感到手足无措。但是，他并没有因此而瘫痪，而是采用多年的江湖经验，遇事不慌，拍个照先的策略，通过记录并分析慢查询的流程，逐步优化查询速度。

第一步，分析SQL语句，检查索引

查询语句中包含了大量的条件，执行查询的速度非常缓慢，由之前的80ms到5.8秒。该查询语句中涉及到的关联表较多。而检查索引时发现re.incident_id和i.flow_id并没有走索引。优化的思路是建立索引。

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

在检查索引的过程中，发现record的type为all，赤裸裸的没走索引。为什么呢？我们采用了explain命令来查看执行计划，发现并没有使用索引。这是为什么呢？我们需要更加仔细地分析。

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

通过分析字段类型和字段长度，我们发现它们完全一致。然而，在继续探索过程中，发现了一个新的线索：event表的id的字符类型为UTF8MB4，而record表的incident_id的字符类型为UTF8。因此，需要将它们统一使用UTF8MB4与项目组保持一致。再次执行explain，查询时间瞬间降至1秒之内。

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

在MySQL中，如果一张表的索引基数过小，那么默认的查询方式很可能是全文搜索，而不是使用索引。因此，在一张业务量过大但是索引基数为同一数据或是NULL的表中，我们需要在sql语句中写强制索引来解决这个问题。

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

IN操作通常是走索引的。只有当IN后面的数据在数据表中超过30%的匹配时，才会进行全表扫描。因此，我们可以使用left join来优化查询。

总结

通过以上五个步骤，我们成功地优化了mysql的慢查询。在实际的应用环境中，我们可以根据实际情况采用相应的优化策略。虽然每个问题的解决过程都是不同的，但是我们可以从这个实例中学到的经验是，当遇到问题时，应当先记录下来，然后再进行分析和解决。通过耐心调试和分析，我们可以找到最佳的优化方案，提高查询速度，从而提高业务的运转效率。

扫码添加UTHEME微信为好友

· 分享WordPress相关技术文章，主题上新与优惠动态早知道。
· 微信端最大WordPress社群，限时免费入群。