本文介绍了一次因子查询导致MySQL服务器崩溃的经历。该SQL每10秒执行一次，最初耗时约1.5秒，后突然增加至100秒，并使服务器负载急剧上升。通过分析执行计划发现虽然使用了索引，但仍然存在性能瓶颈。最终通过将子查询转换为JOIN查询解决了问题。
之前我也知道，mysql 5.6之前的子查询最好改写成join的方式，但是之前认识不够深刻，看执行计划也还好，直到今天主库挂了....
现象：该sql执行频率不算很高，大概10s一次，前两天还算好的，大概1.5s就能出结果，之前没有认识到问题的严重性，直到下午整个mysql崩溃，响应时间超长；表现为该条SQL执行时间超长，变成了将近100s，而每个该查询的连接都会消耗大概1个核的cpu，20个就占用20个核了，严重影响到其他SQL的正常执行
show processlist中state项一直显示为preparing，profile这个sql也是一样。
问题SQL和解析计划：
看情况SQL都走了索引，扫描的行数也不算多，单表记录是2w行，执行时间100s；
在空闲的slave上stop slave后再执行，问题依旧，确定是该SQL引起的；
解决方法：将其改为join，或升级到5.6解决，ms级别返回结果
扫一扫
4万+
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
