先执行 SHOW VARIABLES LIKE 'slow_query_log' 确认是否为 ON，否则后续分析无效；再查 slow_query_log_file（路径与权限）和 long_query_time（阈值及生效范围）。
怎么确认慢查询日志是否真在记录
很多问题其实卡在第一步：你以为日志开着，其实根本没记。先执行 SHOW VARIABLES LIKE 'slow_query_log'，如果返回 OFF，那后续所有分析都是空谈。别信配置文件里写了就生效——MySQL 8.0+ 默认用 slow_query_log = ON，但老版本或 Docker 镜像常默认关着；临时开启用 SET GLOBAL slow_query_log = ON，但重启即失效。
还要顺手查两个关键值：slow_query_log_file 确认日志写到哪（常见坑：路径不存在、MySQL 进程无写权限）；long_query_time 看阈值设的是多少（默认是 10 秒，但业务中 1~2 秒就该警觉）。注意：这个值修改后，新连接才生效，旧连接仍按旧阈值判断。
为什么 mysqldumpslow 有时看不出问题
mysqldumpslow 是 MySQL 自带的轻量工具，适合快速扫一眼高频慢 SQL，但它只做文本聚合，不解析执行计划、不统计锁等待、不区分用户和库。比如两条语句逻辑相同但一个走了索引一个没走，mysqldumpslow 会把它们合并成一条“抽象 SQL”，掩盖真实差异。
更常见的问题是：它默认忽略 SET、COMMIT 等非查询语句，而实际慢因可能藏在事务开启后长时间未提交导致的锁等待里。建议搭配使用 mysqlsla 或 Percona 的 pt-query-digest（后者能解析 Lock_time、Rows_examined 等字段并排序），尤其当你要判断“是 SQL 写得差，还是数据量突增，还是锁冲突”时。
EXPLAIN 结果里哪些字段最值得盯
拿到慢 SQL 后，别急着改，先跑 EXPLAIN FORMAT=TRADITIONAL（或 MySQL 8.0+ 的 FORMAT=JSON 更详细）。重点关注三处：
-
type：出现ALL（全表扫描）或index（全索引扫描）基本等于性能红灯；range或ref才算健康 -
key和possible_keys：如果key为空但possible_keys有值，说明优化器放弃了可用索引——大概率是条件用了函数（如WHERE DATE(create_time) = '2026-01-01'）、隐式类型转换（varchar字段查数字）或统计信息过期 -
rows（或 JSON 中的rows_examined）：这个数不是结果行数，是预估扫描行数。如果它比实际返回行数大几十倍，说明索引没选对，或者WHERE条件过滤性极差
容易被忽略的“非 SQL”慢因
日志里看到某条 SELECT 耗时 3s，第一反应是加索引？先别动。检查它执行时段的系统状态：SHOW ENGINE INNODB STATUS\G 里看 SEMAPHORES 和 TRANSACTIONS 部分，有没有大量线程卡在 waiting for table metadata lock 或 lock wait timeout exceeded；用 SELECT * FROM performance_schema.events_statements_history_long WHERE sql_text LIKE '%你的SQL%' 查它真实的 LOCK_TIME 占比——若 >50%，说明慢在等锁，不是 SQL 本身。
另一个隐形杀手是 log_queries_not_using_indexes = ON 开着但没配 min_examined_row_limit，导致大量低效小查询刷屏日志，反而淹没了真正高危的慢 SQL。生产环境建议设 min_examined_row_limit = 1000，只捕获确实扫了千行以上的“真慢”操作。
