需执行 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 没走索引，这种查询在数据增长后会雪崩。 Murf AI AI文本转语音生成工具