生产环境开启慢查询日志必须同步管控内容、路径、写入与访问边界：验证slow_query_log_file为非空绝对路径且权限正确、long_query_time为浮点数、日志真实落盘；禁用table输出和log_queries_not_using_indexes；long_query_time需按业务节奏调整；os层权限与logrotate必须到位。
不能只开日志就完事——生产环境开启慢查询日志，核心矛盾是「既要捕获真实瓶颈，又不能泄露敏感数据、拖垮性能或埋下权限隐患」。必须同步控制日志内容、存储路径、写入方式和访问边界。
确认 slow_query_log 三要素是否真正生效
很多线上问题不是没慢 SQL，而是日志根本没落盘。只查 @@slow_query_log 是 ON 不够，得验证三件事同时成立：
-
@@slow_query_log_file必须是非空绝对路径（如/var/log/mysql/slow.log），不能是默认值（如/var/lib/mysql/hostname-slow.log） - 该路径所在目录需存在，且属主为
mysql用户、权限至少755；日志文件本身建议设为600 -
@@long_query_time必须是浮点数（如1.0），不能写1或ON；MySQL 5.7 严格校验类型，错一个就静默失败
验证方法：执行 SELECT SLEEP(2); 后立刻跑 tail -n 1 /var/log/mysql/slow.log。如果没输出，再查 SHOW GLOBAL STATUS LIKE 'Slow_queries'; —— 若仍为 0，说明配置未触发，不是“没慢 SQL”，而是“压根没记”。
避免记录明文敏感字段的两个硬约束
慢查询日志会原样记录 SQL 文本，UPDATE users SET password='123456' 这类语句一旦写入，就是高危泄露。不能依赖开发写参数化查询来规避，得从日志层堵死：
- 禁用
log_output = TABLE：写进mysql.slow_log表会加重 InnoDB 刷脏页压力，且表结构暴露更直接；坚持用FILE方式，便于后续用logrotate控制生命周期 - 不启用
log_queries_not_using_indexes除非必要：它会把所有无索引查询都记下来，哪怕执行仅 0.01 秒——大量SELECT * FROM config WHERE key='xxx'类语句极易带出敏感键名或值，增加审计面和泄露风险
如果真需要捕获未走索引的语句，优先用 pt-query-digest --filter 在日志采集后过滤，而非让 MySQL 原始记录。
设置 long_query_time 的实际影响与取值逻辑
long_query_time 不是“越小越好”。设成 0.1 看似精细，但会导致日志量爆炸，尤其在 OLTP 场景下每秒数百条慢查询，I/O 和磁盘空间立刻告急：
- 业务峰值期，建议先设为
2.0，观察Slow_queries计数器增长速率；若每分钟新增不足 10 条，再逐步下调到1.0或0.5 - 注意：MySQL 5.7 中
long_query_time对已建立连接不生效，新连接才读取全局值；所以动态修改后要等连接池重建或重启应用 - 别信“阈值设为 0 就能抓全”——它会记录所有查询，包括
SELECT 1，日志体积膨胀数十倍，且掩盖真正耗时的瓶颈点
权限与轮转必须落地到操作系统层
MySQL 进程以 mysql 用户身份写日志，但运维人员通常用 root 查看。权限错配会导致两种典型故障：
- 日志文件被创建但内容为空：因为
mysql用户对父目录无写权限，openat()系统调用失败，MySQL 不报错但静默丢弃日志 - 运维误删或误读日志：
/var/log/mysql/slow.log被设为644，任意用户都能cat，密码、手机号、订单号全暴露
正确做法：sudo chown mysql:mysql /var/log/mysql + sudo chmod 700 /var/log/mysql + sudo chmod 600 /var/log/mysql/slow.log；再配 logrotate 每天切割、保留 7 天、自动压缩，避免单文件超 500MB 影响 mysqldumpslow 解析速度。
最常被忽略的是：日志路径的父目录权限和 long_query_time 的连接生效延迟。这两点不检查，日志可能开着却等于没开，问题照样漏掉。
