慢查询日志默认关闭，需手动开启；确认方法为执行show variables like 'slow_query_log'返回off即未开启；临时开启用set global三命令，永久开启须修改my.cnf中slow_query_log=1、slow_query_log_file绝对路径、long_query_time=1.0，并确保路径权限正确且重启服务。
默认是关闭的，必须手动开启，否则日志文件永远不会生成——哪怕配置写对了，不重启或不执行 SET GLOBAL，slow_query_log 值始终是 OFF。
怎么确认慢查询日志当前没开？
别靠猜，直接连上 MySQL 执行：
-
SHOW VARIABLES LIKE 'slow_query_log';—— 返回OFF就没开 -
SHOW VARIABLES LIKE 'long_query_time';—— 默认是10.000000，对现代业务基本无效 -
SHOW VARIABLES LIKE 'slow_query_log_file';—— 如果返回空字符串，说明slow_query_log_file没配或配错位置
常见静默失败现象：日志文件存在但没新内容、SELECT SLEEP(2) 后查不到记录、变量显示 ON 但日志路径不可写。
临时开启：快速验证是否生效
适合刚装好想立刻测试，或临时排查问题。执行这三条命令：
-
SET GLOBAL slow_query_log = 'ON';—— 必须用字符串'ON'，数字1在部分版本会报错 -
SET GLOBAL long_query_time = 1;—— 建议设成1或0.5，比默认10更敏感 -
SET GLOBAL log_queries_not_using_indexes = 'ON';—— 强烈推荐，能抓到“没走索引”的隐患 SQL
注意：SET GLOBAL 只影响新建立的连接；已存在的连接仍用旧值；MySQL 重启后全部失效。验证是否真写入，得去日志文件里搜 SELECT SLEEP(2) 的记录，不能只看命令回显。
永久开启：改配置文件 + 重启服务
生产环境必须走这条路。关键不是“写了配置”，而是三件事同时做对：
- 在正确的配置文件里、
[mysqld]段落内添加（Linux 常见路径：/etc/my.cnf或/etc/mysql/mysql.conf.d/mysqld.cnf；宝塔用户可能是/www/server/mysql/etc/my.cnf；Docker 容器里常是/etc/mysql/conf.d/mysql.cnf） - 必须同时写全三项（缺一不可）：
slow_query_log = 1、slow_query_log_file = /var/log/mysql/mysql-slow.log（绝对路径！）、long_query_time = 1.0 - 路径权限要提前搞定：
sudo mkdir -p /var/log/mysql && sudo chown mysql:mysql /var/log/mysql
特别注意：my.cnf 里用连字符 slow-query-log 是错的，必须是下划线 slow_query_log；log_output = FILE 要显式指定，否则可能默默写进 mysql.slow_log 表里，你根本找不到日志在哪。
重启后必须验证日志是否真实生成
重启不是终点。执行：
-
sudo systemctl restart mysqld（CentOS/RHEL）或sudo service mysql restart（Ubuntu/Debian） - 再登录 MySQL 查：
SELECT @@slow_query_log, @@slow_query_log_file, @@long_query_time; - 然后跑一句：
SELECT SLEEP(2); - 最后检查文件：
sudo tail -n 10 /var/log/mysql/mysql-slow.log
最容易被忽略的是：日志路径权限不对、配置文件读错了（比如改了 /etc/my.cnf，但 MySQL 实际加载的是 /etc/mysql/my.cnf）、slow_query_log_file 写成相对路径（MySQL 会自动忽略），这三处出问题，日志就静默失败，没有任何报错提示。
