慢查询日志只指出“谁慢了”，需结合Rows_examined/Rows_sent比值、Query_time与Lock_time差值及EXPLAIN三者交叉验证定位扫描、锁等待或排序等具体瓶颈阶段。
慢查询日志本身不告诉你瓶颈在哪一阶段，它只告诉你“谁慢了”；真正定位到扫描、排序、连接或锁等待等具体瓶颈阶段，必须结合日志字段 + EXPLAIN + 实时状态三者交叉验证。
看 Rows_examined 和 Rows_sent 的比值，判断是否在“扫描阶段”浪费资源
这是最直接的信号。如果一条 SQL 返回 10 行，但 Rows_examined 是 200 万，基本可以断定：索引没用上，或者用了低效索引，正在做大量无效行扫描。
-
Rows_examined ≈ Rows_sent：扫描精准，大概率走了合适索引（如type=ref或const） -
Rows_examined >> Rows_sent（比如 100 倍以上）：典型全表扫描或索引失效，重点查WHERE条件是否触发隐式转换、函数包裹、最左前缀缺失 -
Rows_examined很大，但Query_time不高：说明瓶颈不在 CPU/IO，可能在内存带宽或缓冲区争用，需结合SHOW GLOBAL STATUS LIKE 'Innodb_buffer_pool_read%'看物理读比例
盯住 Query_time 和 Lock_time 的差值，识别“锁等待”还是“真执行慢”
日志里这两项是分开记录的：Lock_time 是事务等待行锁/表锁的时间，Query_time 是整个语句从解析到返回的总耗时。它们的差值能快速区分问题类型。
-
Lock_time / Query_time > 0.7：大部分时间花在等锁上，不是 SQL 写得差，而是并发冲突严重（比如高频更新同一行、长事务未提交） -
Lock_time接近 0，但Query_time高：问题在执行逻辑本身，下一步必须跑EXPLAIN看执行计划 -
Lock_time为 0，Query_time高，且Rows_examined合理 → 往Extra里找Using filesort或Using temporary，说明瓶颈在排序或分组阶段
用 EXPLAIN FORMAT=JSON 补全日志缺失的执行细节
慢日志只记结果，EXPLAIN 才揭示过程。但普通 EXPLAIN 输出太简略，尤其对 JOIN 或子查询，容易误判。必须用 FORMAT=JSON：
安装、修复、更新或打包一个基于 Python 和 PyMySQL 实现的 Windows `mysql` 命令。适用于用户希望在 PowerShell/CMD 中输入 `mysql` 时重定向到 Python 实现、需要交互式输入 MySQL 连接信息、需要同步到当前用户本地 bin 目录，或需要将该能力封装成可公开复用的 Codex skill。
- 看
used_columns字段：确认优化器实际用了哪些列走索引，避免你以为覆盖了，其实只用了前缀 - 查
pushed_condition：如果为空，说明 WHERE 条件没下推到存储引擎层，可能在 Server 层做过滤，效率低 - 注意
filtered值：低于 10（即 10%）意味着优化器预估 90% 的索引扫描行会被过滤掉，这时候加索引收益极小，该重写条件或拆查询 - 别信
rows：它是估算值；对比日志里的Rows_examined，如果偏差超过 5 倍，说明统计信息过期，该跑ANALYZE TABLE
临时启用 log_slow_extra（MySQL 8.0.14+），让日志自带瓶颈线索
默认慢日志字段太少，8.0.14 起支持这个开关，开启后每条记录自动补上 Rows_examined、Lock_time、Bytes_sent 等关键指标，不用再手动拼接分析。
- 动态开启：
SET GLOBAL log_slow_extra = ON;（需同时开启slow_query_log） - 配置文件加一行：
log_slow_extra = ON，重启生效 - 注意：它只对新记录的日志生效，旧日志不会 retroactively 补全
- 配合
log_output = FILE使用最稳；若设成TABLE，写入mysql.slow_log表会带来额外 InnoDB 开销，线上慎用
最容易被忽略的是：日志里 Query_time 的精度单位。2026 年主流 MySQL 版本（8.0.22+）默认记微秒，但很多运维脚本仍按毫秒解析，导致 mysqldumpslow -s at 排序错乱、阈值误判。验证方式很简单：head -n 3 /var/log/mysql/mysql-slow.log 看第一行 Query_time 是否带 6 位小数。不是所有“慢”都该优化——有些是锁等出来的，有些是排序撑起来的，有些压根不该进慢日志（比如定时归档任务）。分清阶段，才能下对药。
