MySQL 8.0慢查询日志必须修改my.cnf并重启生效，SET GLOBAL仅临时开启且不持久；确认启用需执行SHOW VARIABLES LIKE 'slow_query_log'返回ON，否则未生效；关键配置包括slow_query_log = ON、long_query_time = 1.0、slow_query_log_file = /var/log/mysql/slow.log及log_output = FILE，并验证SELECT SLEEP(2)是否写入日志。
MySQL 8.0 的慢查询日志必须通过配置文件修改并重启生效，SET GLOBAL 只能临时开启但不持久，且对已存在的连接无效。
确认 slow_query_log 是否真正启用
别信配置文件里写了就等于开了。连上 MySQL 后直接执行：SHOW VARIABLES LIKE 'slow_query_log';，返回值必须是 ON 才算启用。如果返回 OFF，说明配置没生效或被覆盖——常见原因是改错了配置文件（比如改了 /etc/my.cnf，但 mysqld 实际加载的是 /etc/mysql/my.cnf），可用 mysqld --help --verbose | grep "Default options" 查它到底读哪个文件。
顺手再查两个关键变量：SHOW VARIABLES LIKE 'slow_query_log_file'; 看日志写到哪（不是默认路径！）；SHOW VARIABLES LIKE 'long_query_time'; 看当前阈值（MySQL 8.0 默认仍是 10.0，不是业务能接受的值）。
my.cnf 必须写的三行配置
在 [mysqld] 段下只写这三行，多余参数反而干扰判断：
-
slow_query_log = ON—— 必须大写ON，1、true、on都会静默失败甚至导致启动报错 -
long_query_time = 1.0—— 单位秒，支持小数；注意：该值对已有连接不生效，只影响新连接 -
slow_query_log_file = /var/log/mysql/slow.log—— 路径需绝对路径，父目录必须存在，且属主为mysql用户；用sudo -u mysql touch /var/log/mysql/slow.log测试是否可写
额外但强烈建议加一行：log_output = FILE。因为如果之前运行过 SET GLOBAL log_output = 'TABLE'，重启后即使 slow_query_log = ON，日志也不会写入文件——MySQL 不报错，但日志静默丢失。
验证配置是否真起作用
重启服务后别等业务流量，立刻用 SELECT SLEEP(2); 触发一条明确超时的语句，然后马上检查日志文件：tail -n 5 /var/log/mysql/slow.log。能看到类似这样的内容才算成功：
# Time: 2026-10-13T18:22:33.456789Z # User@Host: root[root] @ localhost [] Id: 123 # Query_time: 2.000123 Lock_time: 0.000000 Rows_sent: 1 Rows_examined: 1 use test; SELECT SLEEP(2);
常见失败原因包括：
- SELinux 或 AppArmor 拦截写入，用
ausearch -m avc -ts recent | grep mysqld查拒绝记录 -
slow_query_log_file路径的父目录权限不对，MySQL 启动时不报错但日志根本不会生成 -
log_output被设成TABLE或NONE，导致日志无处可落 - 应用使用长连接池，旧连接仍按默认
10.0判断，需重连或手动执行SET SESSION long_query_time = 1.0
DML 语句（INSERT/UPDATE/DELETE）默认不进慢日志
这是 MySQL 默认行为，不是配置错误。即使 INSERT INTO ... SELECT 执行了 5 秒，也不会出现在慢日志里。如果你真需要记录 DML，得额外开启 log_slow_admin_statements = ON（注意：它只影响部分管理类语句，不覆盖所有 DML）；更稳妥的做法是结合 Performance Schema 的 events_statements_history_long 表做实时抓取——但这属于另一套监控体系，和慢日志本身无关。
真正容易被忽略的点是：long_query_time 只计算语句纯执行耗时，不包含锁等待时间；而线上最卡的往往就是锁住等了几秒才执行完的 SQL——这类语句可能根本达不到阈值，却拖垮整个系统。所以光看慢日志远远不够，得配合 information_schema.INNODB_TRX 和 sys.innodb_lock_waits 一起分析。
