需执行 SET GLOBAL slow_query_log = ON 或重启生效，再用 SELECT SLEEP(11) 测试日志是否生成；确认 slow_query_log_file 路径权限正确且 log_queries_not_using_indexes 已开启才能完整记录。
怎么确认 slow_query_log 真的在记录？
很多人改了配置却看不到日志，不是没生效，而是根本没触发记录条件。MySQL 默认只记录执行时间超过 long_query_time（默认 10 秒）且未使用索引的查询——但后者要靠 log_queries_not_using_indexes 显式开启，而这个选项默认是关的。
-
slow_query_log必须设为ON，且slow_query_log_file路径 MySQL 进程要有写权限（常见坑：路径存在但属主是 root，mysqld 用户写不进去） - 修改后必须执行
SET GLOBAL slow_query_log = ON或重启 mysqld；仅改 my.cnf 不 reload 是无效的 - 测试是否生效：用
SLEEP(11)强制触发（SELECT SLEEP(11)），再查日志文件末尾是否有对应条目
log_output=FILE 和 log_output=TABLE 选哪个？
日志输出方式直接影响排查效率和运维负担。log_output 设为 TABLE 时，日志写入 mysql.slow_log 表，能用 SQL 查、加索引、导出分析；设为 FILE 则是纯文本，适合快速追加、配合 shell 工具处理，但没法直接 join 其他表。
-
log_output=TABLE的代价：每次慢查询都会触发一次 INSERT，高并发下可能拖慢主线程（尤其表没主键或没索引时）；建议定期清空 + 开启slow_log表的ENGINE=CSV或用归档表替代 -
log_output=FILE更轻量，但日志轮转得自己做（比如用 logrotate），否则单文件暴涨；路径别设在 /tmp 下——有些系统会定时清理 - 混合模式
log_output='FILE,TABLE'很少必要，反而增加 I/O 和一致性风险
怎么看 slow_log 里真正危险的查询？
不是耗时长就一定有问题，关键看 Rows_examined 和 Rows_sent 的比值。比如 Rows_examined: 500000 却只 Rows_sent: 1，大概率是全表扫描+ LIMIT 1 没走索引，这种查询在数据增长后会雪崩。
- 重点关注
Query_time高但Lock_time也高的语句——说明锁争用严重，不单是查询慢，还卡别人 - 忽略
admin commands类日志（如Flush tables），它们是管理操作，不反映业务 SQL 质量 - 用
mysqldumpslow -s t -t 10 /var/lib/mysql/localhost-slow.log快速聚合 Top 10 最耗时语句；加-g 'WHERE'可过滤含 WHERE 的查询，避开无意义的SELECT *
为什么开了 slow_query_log 还漏掉“伪慢查询”？
某些查询本身快，但因事务长、锁等待、网络延迟或客户端超时重试，被误认为慢。它们不会进 slow_log，但实际拖垮服务。典型如：自动提交关闭后的大事务、存储过程中嵌套的短查询、或应用层反复重试失败的 INSERT ... ON DUPLICATE KEY UPDATE。
- 这类问题得结合
performance_schema.events_statements_summary_by_digest查平均延时和错误频次，而不是只盯 slow_log -
innodb_print_all_deadlocks=ON配合 error log，能暴露死锁链路——死锁本身不记 slow_log，但反复死锁会让相关查询变慢 - 应用端加 trace ID 并打点，比依赖 MySQL 日志更容易定位“看起来不慢，但用户觉得卡”的场景
slow_query_log 是入口，不是终点。真正难的是区分“慢在 SQL 本身”和“慢在上下文”，而后者往往藏在连接池配置、事务边界、甚至 DNS 解析里。
