遇事不慌,先记录:mysql in慢查询优化

藏色散人
发布: 2022-11-08 16:47:53
转载
1974人浏览过

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

遇事不慌,先记录:mysql in慢查询优化

记一次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的字符类型为:

image.png

record表的incident_id的字符类型为:

image.png

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

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

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

image.png

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

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

以上就是遇事不慌,先记录:mysql in慢查询优化的详细内容,更多请关注php中文网其它相关文章!

最佳 Windows 性能的顶级免费优化软件
最佳 Windows 性能的顶级免费优化软件

每个人都需要一台速度更快、更稳定的 PC。随着时间的推移,垃圾文件、旧注册表数据和不必要的后台进程会占用资源并降低性能。幸运的是,许多工具可以让 Windows 保持平稳运行。

下载
相关标签:
来源:juejin网
本文内容由网友自发贡献,版权归原作者所有,本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容,请联系admin@php.cn
最新问题
开源免费商场系统广告
热门教程
更多>
最新下载
更多>
网站特效
网站源码
网站素材
前端模板
关于我们 免责申明 意见反馈 讲师合作 广告合作 最新更新
php中文网:公益在线php培训,帮助PHP学习者快速成长!
关注服务号 技术交流群
PHP中文网订阅号
每天精选资源文章推送
PHP中文网APP
随时随地碎片化学习
PHP中文网抖音号
发现有趣的

Copyright 2014-2025 https://www.php.cn/ All Rights Reserved | php.cn | 湘ICP备2023035733号