mysql in索引慢查询优化实现步骤解析
记一次mysql慢查询优化
生产环境待办列表现场演示5~6s才加载出来结果;顿时,产品经理的脸挂不住了,作为多年经验的老开发,心想完犊子,脸啪啪滴。
不过,秉着多年的江湖经验,遇事不慌,拍个照先。
第一步、分析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慢查询优化的详细内容,更多关于mysql in慢查询优化的资料请关注脚本之家其它相关文章!
相关文章
关于Mysql update修改多个字段and的语法问题详析
这篇文章主要给大家介绍了关于mysql update修改多个字段and的语法问题的相关资料,文中通过示例代码介绍的非常详细,对大家的学习或者工作具有一定的参考学习价值,需要的朋友们下面随着小编来一起学习学习吧2020-12-12一文搞懂Mysql中的共享锁、排他锁、悲观锁、乐观锁及使用场景
刚开始学习MySQL中锁的时候,网上一查出来一堆,什么表锁、行锁、读锁、写锁、悲观锁、乐观锁等等等,直接整个人就懵了,下面这篇文章主要给大家介绍了关于Mysql中共享锁、排他锁、悲观锁、乐观锁及使用场景的相关资料,需要的朋友可以参考下2022-07-07MYSQL ON UPDATE CURRENT_TIMESTAMP当字段值发生改变时才会更
本文主要介绍了MYSQL ON UPDATE CURRENT_TIMESTAMP当字段值发生改变时才会更新记录的时间,文中通过示例代码介绍的非常详细,对大家的学习或者工作具有一定的参考学习价值,需要的朋友们下面随着小编来一起学习学习吧2023-01-01
最新评论