MySQL如何快速排查慢查询安全隐患_分析slow_query_log进行优化

需执行 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 进程要有写权限常见坑路径存在但属主是 rootmysqld 用户写不进去修改后必须执行 SET GLOBAL slow_query_log ON 或重启 mysqld仅改 my.cnf 不 reload 是无效的测试是否生效用 SLEEP(11) 强制触发SELECT SLEEP(11)再查日志文件末尾是否有对应条目log_outputFILE 和 log_outputTABLE 选哪个日志输出方式直接影响排查效率和运维负担。log_output 设为 TABLE 时日志写入 mysql.slow_log 表能用 SQL 查、加索引、导出分析设为 FILE 则是纯文本适合快速追加、配合 shell 工具处理但没法直接 join 其他表。log_outputTABLE 的代价每次慢查询都会触发一次 INSERT高并发下可能拖慢主线程尤其表没主键或没索引时建议定期清空 开启 slow_log 表的 ENGINECSV 或用归档表替代log_outputFILE 更轻量但日志轮转得自己做比如用 logrotate否则单文件暴涨路径别设在 /tmp 下——有些系统会定时清理混合模式 log_outputFILE,TABLE 很少必要反而增加 I/O 和一致性风险怎么看 slow_log 里真正危险的查询不是耗时长就一定有问题关键看 Rows_examined 和 Rows_sent 的比值。比如 Rows_examined: 500000 却只 Rows_sent: 1大概率是全表扫描 LIMIT 1 没走索引这种查询在数据增长后会雪崩。 Murf AI AI文本转语音生成工具