MySQL慢查询日志默认关闭，必须显式开启；通过SHOW VARIABLES确认slow_query_log为ON、路径可写、long_query_time合理，再用SELECT SLEEP()实测验证。
MySQL 慢查询日志必须显式开启，且默认关闭；不改配置或不执行 SET GLOBAL 命令，slow_query_log 始终为 OFF，日志不会产生任何记录。
确认当前 slow_query_log 是否已生效
很多问题其实卡在「以为开好了，其实没开」。直接查变量最可靠：
SHOW VARIABLES LIKE 'slow_query_log'; —— 返回 ON 才算启用SHOW VARIABLES LIKE 'slow_query_log_file'; —— 看路径是否存在、MySQL 进程是否有写权限SHOW VARIABLES LIKE 'long_query_time'; —— 注意：该值是浮点数（如 1.000000），设为 1 和 1.0 效果一致，但设为 0 会记录所有查询（含毫秒级），不推荐
常见错误现象：
- 日志文件存在但无新内容 → slow_query_log 实际是 OFF
- 日志文件为空或只有一两行 → long_query_time 设得太大（比如仍用默认 10），而实际慢 SQL 都在 2–3 秒左右
- 查看变量返回 OFF，但配置文件里写了 → 忘记重启 MySQL 或未执行 SET GLOBAL 动态生效
两种开启方式：临时生效 vs 永久生效
动态设置（无需重启，但 MySQL 重启后失效）：
-
SET GLOBAL slow_query_log = 'ON';—— 必须用字符串'ON'或'OFF'，数字1在部分版本会报错 -
SET GLOBAL slow_query_log_file = '/var/log/mysql/slow.log';—— 路径需 MySQL 用户（如mysql）有写权限，目录必须提前创建 -
SET GLOBAL long_query_time = 2;—— 此命令对**后续新连接**生效；已存在的连接沿用旧值 -
SET GLOBAL log_queries_not_using_indexes = 'ON';—— 额外捕获无索引查询，调试阶段建议打开
配置文件修改（永久生效，需重启）：
编辑 /etc/my.cnf（Linux）或 C:my.ini（Windows），在 [mysqld] 段下添加：
[mysqld] slow_query_log = ON slow_query_log_file = /var/log/mysql/slow.log long_query_time = 2 log_queries_not_using_indexes = ON
注意：
- MySQL 5.6+ 不再支持 log-slow-queries 这种旧写法，必须用 slow_query_log 和 slow_query_log_file
- Windows 下路径用正斜杠 / 或双反斜杠 \，避免单反斜杠被转义
- 修改后必须执行 systemctl restart mysqld 或 service mysql restart，仅 reload 不生效
验证日志是否真正在记录
别依赖“文件存在”或“服务重启了”，要实测：
- 在客户端执行
SELECT SLEEP(3);（确保超过long_query_time） - 立刻检查日志文件末尾：
tail -n 10 /var/log/mysql/slow.log - 正常应看到类似条目：
# Time: 2026-04-20T05:22:18.123456Z<br># User@Host: root[root] @ localhost [] Id: 12<br># Query_time: 3.000211 Lock_time: 0.000000 Rows_sent: 1 Rows_examined: 1<br>use test;<br>SELECT SLEEP(3);
- 如果没出现，重点排查：
–slow_query_log变量是否真为ON
– 日志路径目录权限（chown mysql:mysql /var/log/mysql）
– SELinux 或 AppArmor 是否拦截写入（Linux 上可临时setenforce 0测试）
性能与误用风险提醒
慢查询日志不是“开得越细越好”：
- 开启
log_queries_not_using_indexes后，哪怕SELECT * FROM user WHERE id = 1（主键查询）也会被记录——因为优化器判定“全表扫描成本更低”，实际并不慢；这会产生大量干扰日志 -
long_query_time = 0会记录所有语句，I/O 开销显著上升，生产环境严禁使用 - 日志文件不轮转，长期运行可能撑爆磁盘；建议配合
logrotate或定期mv+FLUSH LOGS - 日志分析别手动翻：用
mysqldumpslow -s t -t 10 /var/log/mysql/slow.log快速定位耗时 Top 10 查询
真正关键的不是“怎么开”，而是“开多久、记什么、谁来读”。线上先设 long_query_time = 2 观察 1–2 天，再决定是否调低或打开 log_queries_not_using_indexes。日志本身不解决问题，它只告诉你哪条 SQL 值得花时间看执行计划。
