mysql慢查询日志怎么开启_修改my.cnf配置与设置long_query

直接执行show variables like 'slow_query_log%';和show variables like 'long_query_time';可确认mysql慢查询日志是否启用；若slow_query_log为off则配置无效，slow_query_log_file指示实际日志路径，且修改my.cnf后必须重启mysqld生效。

mysql慢查询日志怎么开启_修改my.cnf配置与设置long_query_time

如何确认 MySQL 是否已启用慢查询日志

直接查变量比翻配置更可靠：SHOW VARIABLES LIKE 'slow_query_log%'; 和 SHOW VARIABLES LIKE 'long_query_time';。如果 slow_query_log 是 OFF，哪怕 my.cnf 里写了也白搭；slow_query_log_file 的值会告诉你日志实际写到哪，别默认它在 /var/lib/mysql/ 下——很多云数据库或 Docker 部署路径完全不同。

修改 my.cnf 开启慢查询并设 long_query_time

必须重启 mysqld 才生效（动态 SET 只能临时改部分参数，slow_query_log 本身不支持动态开启）。关键配置项就三个：

slow_query_log = ON（必须大写 ON，用 1 或 true 无效）
slow_query_log_file = /var/log/mysql/mysql-slow.log（确保目录存在、MySQL 进程有写权限，否则启动失败）
long_query_time = 1.0（单位是秒，支持小数；注意：5.7+ 默认是 10.0，但 8.0+ 对于带锁等待的语句，该阈值只计算执行时间，不含锁等待）

别漏掉 log_output = FILE（默认值，但如果之前设过 TABLE，日志会写进 mysql.slow_log 表，不是文件）。

MySQL（Linux）

MySQL 9.6.0是面向Linux平台的2026年创新版本，核心架构迎来重大革新。其将外键约束与级联操作从InnoDB引擎层上移至SQL层，确保所有数据变更均被完整记录至Binlog，彻底解决了CDC（变更数据捕获）与主从复制中的数据不一致难题。此外，该版本引入container_aware启动选项以原生适配容器环境，并对审计日志进行了组件化重构，为追求极致数据一致性与云原生体验的开发者提供了全新选择。

下载

long_query_time 设太小会导致日志爆炸

设成 0 理论上记录所有查询，但线上库几乎不可行：QPS 高时 I/O 压力陡增，还可能拖慢主库性能。常见误操作是设 0.1 或 0.01 调试完忘了调回去。建议：

压测阶段可临时设 0.5，上线后调回 1.0 或 2.0
搭配 log_queries_not_using_indexes = ON 更有针对性，但要注意它不判断索引是否真的被用上（比如用了索引但回表太多，它也不报）
MySQL 8.0+ 可用 pt-query-digest 定期分析，别靠人工翻日志

为什么改了配置重启后 still no slow log

最常踩的坑不是配置写错，而是：

MySQL 实际读的不是你以为的 my.cnf：用 mysqld --help --verbose | grep "Default options" 看加载顺序，常见优先级是 /etc/my.cnf → /etc/mysql/my.cnf → /usr/etc/my.cnf → ~/.my.cnf
配置写在 [client] 段而非 [mysqld] 段（慢查询日志是服务端功能，客户端段无效）
SELinux 或 AppArmor 拦截了文件写入，tail -f /var/log/audit/audit.log | grep mysqld 能看到拒绝记录

真正起效前，先 SELECT SLEEP(2); 测试下日志有没有新内容——比等业务流量快得多。