SQL慢查询怎么排查_标准流程说明避免常见使用误区【指导】

SQL慢查询排查需按标准四步走：先开启合理阈值的慢查询日志并指定安全路径；再从真实日志提取带实际参数的SQL分析频次与扫描行数；接着用EXPLAIN紧盯type、key、Extra三列定位执行瓶颈；最后依场景建复合索引、精简字段、优化子查询并验证效果。

SQL慢查询排查不是靠猜，而是有标准节奏：先让问题“显形”，再定位根因，最后验证效果。跳过前面步骤直接改SQL或加索引，90%会白忙活。

第一步：必须开慢查询日志，且设对阈值

不开启日志，等于闭眼修车。线上默认10秒才记日志，完全没用。

• 生产环境建议从0.5秒起步（高并发可压到200ms），别一上来就设0.1——日志爆炸、磁盘撑爆、运维翻脸
• 配置方式（my.cnf）：slow_query_log = 1，long_query_time = 0.5
• 顺手打开log_queries_not_using_indexes = ON，能抓到“明明有索引却没走”的隐形坑
• 日志路径务必指定非系统盘，避免写满导致MySQL挂掉

第二步：看真实慢日志，还原真实参数

不要拿开发环境随便拼的SQL去explain——参数不同，执行计划可能天差地别。

• 从慢日志里复制完整SQL，注意检查WHERE条件里的实际值（比如tenant_id = 123456789而不是tenant_id = ?）
• 确认该SQL在日志中出现频次和平均耗时，优先处理高频+高耗时组合
• 留意Rows_examined（扫描行数）是否远大于Rows_sent（返回行数），差距大说明过滤效率低

第三步：用EXPLAIN看执行计划，盯死三处

EXPLAIN不是扫一眼就行，重点只看三个位置：

标签： mysql ai 开发环境 隐式转换