先执行show variables like 'slow_query_log'等命令确认slow_query_log为on、long_query_time合理、slow_query_log_file路径可写；再用select sleep(2)测试日志是否真实生成。
如何确认慢查询日志是否真正开启并写入
很多情况下你以为开了慢查询日志，其实 slow_query_log 是 OFF，或者 long_query_time 设得太高（比如默认 10 秒），导致实际执行 2 秒的聚合 SQL 根本不记录。先连上 MySQL 执行：
SHOW VARIABLES LIKE 'slow_query_log';<br>SHOW VARIABLES LIKE 'long_query_time';<br>SHOW VARIABLES LIKE 'slow_query_log_file';注意
slow_query_log_file 路径是否可写——常见坑是 MySQL 进程用户（如 mysql）对目录无写权限，日志文件空但无报错；用 ls -l 看父目录权限，别只查文件是否存在。
如何从慢日志里快速识别真实瓶颈 SQL
MySQL 慢日志不是纯 SQL 列表，每条记录包含时间戳、锁等待、扫描行数、返回行数等关键线索。重点盯这三个字段：
-
Rows_examined：远大于Rows_sent？说明 WHERE 条件没走索引，全表扫描了 -
Lock_time高（比如 > 100ms）？说明被其他事务阻塞，不是 SQL 本身慢 - 出现
Using filesort或Using temporary？执行计划已退化，需看EXPLAIN对应语句
如何用 pt-query-digest 分析日志并排序热点
手动翻日志效率极低，pt-query-digest 是 DBA 实际在用的工具。安装后执行：
pt-query-digest /var/lib/mysql/mysql-slow.log --limit 10它默认按响应时间总和排序，但更要看
Rank 列下的 Query_time 和 Rows_examined 的比值：同一类 SQL 如果 Rows_examined 波动极大（比如从 100 到 100 万），说明参数不同导致执行计划突变，得单独抓出那些高波动的 SQL 再 EXPLAIN。注意加 --filter '$event->{db} && $event->{db} =~ /^orders/' 可限定库，避免跨库干扰。
为什么有些“快 SQL”也会进慢日志
因为慢日志记录的是单次执行超阈值的语句，不是平均耗时。比如一个 SELECT COUNT(*) FROM logs WHERE day = '2024-01-01' 平时 50ms，但某天该分区数据暴涨 10 倍，一次扫了 800 万行，耗时 3.2 秒——它就进了日志。这类问题不会在 EXPLAIN 里暴露（执行计划没变），得结合 Rows_examined 和业务时间点交叉判断。另外，SET profiling = 1 在生产环境慎用，它本身有性能开销，且只对当前会话有效，无法回溯历史。
