先用 show variables 确认 slow_query_log=on 且 long_query_time 设为合理值（如0.5），再检查 slow_query_log_file 路径权限；日志格式正常应含 query_time、lock_time、rows_examined；rows_examined 远大于 rows_sent 表明索引失效，需结合 explain 分析 type、key、extra。
如何确认慢查询日志是否真的在记录
很多情况下你以为开启了慢查询，其实根本没生效——slow_query_log 是开关，但默认是 OFF，且即使开了，long_query_time 默认是 10 秒，业务里跑个 2 秒的 SQL 就卡顿，这个阈值显然没用。
-
SET GLOBAL slow_query_log = ON只对新连接生效，已连上的会话不记录 -
long_query_time支持小数（比如0.5），单位是秒，设成0可记录所有查询（仅调试用，别上生产） - 检查日志路径：
slow_query_log_file的值，确保 MySQL 进程有写权限，否则日志静默失败，连报错都不会打 - 用
SHOW VARIABLES LIKE 'slow_query_log%'和SHOW VARIABLES LIKE 'long_query_time'确认当前值，别只看配置文件
慢查询日志格式混乱？先统一用 mysqldumpslow 解析
原生日志是文本块拼接的，没有结构化字段，直接 grep 或 awk 容易漏掉关键信息，比如没显示锁等待时间、没合并重复模式。
-
mysqldumpslow -s t -t 10 /var/log/mysql/mysql-slow.log按总耗时排序取前 10 条，-s t是核心，-s c是按出现次数排 - 注意
mysqldumpslow会自动归一化 SQL（把WHERE id = 123变成WHERE id = N），避免被参数值干扰判断 - 如果日志里大量出现
# Time: ... # User@Host: ... # Query_time: ... Lock_time: ... Rows_sent: ... Rows_examined: ...这种头，说明格式正常；缺Lock_time或Rows_examined往往意味着日志版本太老或配置不对
Rows_examined 远大于 Rows_sent 就要警惕
这是最实在的性能线索：MySQL 扫了 10 万行才返回 1 行，基本等于没走对索引，或者索引失效了。
- 常见诱因：
WHERE条件用了函数（如WHERE DATE(create_time) = '2024-01-01'）、隐式类型转换（varchar字段跟数字比较）、OR连接多个非索引列 - 用
EXPLAIN看执行计划时，重点盯type（至少要是ref或range，ALL是全表扫描）、key（实际用的索引名）、Extra（出现Using filesort或Using temporary就得优化） - 注意
Rows_examined是存储引擎层统计的，InnoDB 下它包含回表次数，所以联合索引覆盖不全也会拉高这个值
线上不敢开慢日志？用 Performance Schema 替代
慢查询日志要写磁盘，IO 压力大，尤其 QPS 高时可能拖慢实例；Performance Schema 是内存中采集，开销低得多，适合临时诊断。
- 先开采集：
UPDATE performance_schema.setup_consumers SET ENABLED = 'YES' WHERE NAME = 'events_statements_history_long'; - 查最近慢语句：
SELECT DIGEST_TEXT, AVG_TIMER_WAIT/1000000000000 AS avg_sec, COUNT_STAR FROM performance_schema.events_statements_summary_by_digest WHERE AVG_TIMER_WAIT > 1000000000000 ORDER BY AVG_TIMER_WAIT DESC LIMIT 10; - 注意
DIGEST_TEXT是标准化后的 SQL，和mysqldumpslow效果类似；但 P_S 不记录具体执行时间戳和客户端信息，定位“哪次请求慢”不如慢日志直接
真正难的不是找到慢 SQL，而是判断它为什么慢——有时候执行计划没变，但数据分布变了、统计信息过期了、buffer pool 没预热，这些都得结合 SHOW INDEX、ANALYZE TABLE、INFORMATION_SCHEMA.INNODB_BUFFER_POOL_STATS 交叉验证。别只盯着日志本身。
