MySQL long_query_time 设置为 0 后日志爆炸的合理阈值

设为0会导致全量记录而失控；推荐值为0.1~2秒，需结合log_output、min_examined_row_limit等参数协同控制，并确保磁盘空间与权限正常。

long_query_time 设为 0 确实会记录所有查询，但不是“合理”而是“失控”

mysql 的 long_query_time 设为 0 时，**任何执行时间大于 0 秒的语句都会被记录**——注意，几乎所有非空查询（哪怕只查一行）实际耗时都 > 0.000001 秒，因此等效于“全量记录”。这不是阈值调低，是日志开关被暴力打开，磁盘 IO、写入延迟、日志轮转压力会指数级上升。

生产环境推荐的 long_query_time 范围：0.1 ~ 2 秒

这个范围取决于你的业务响应要求和数据库负载能力：

• 0.1：适合对延迟极度敏感的系统（如实时风控、高频交易），但需确认 slow log 写入不拖慢主实例；
• 1.0：大多数 Web 应用的平衡点，能捕获明显拖慢页面的查询，又不过载日志；
• 2.0：IO 或 CPU 常年吃紧的老旧实例，或只做周期性慢查审计（如每天抽样分析），可放宽；
• 超过 5.0 基本失去 slow log 意义——用户已感知卡顿，问题早该在监控里暴露了。

比数值更重要的是配合 log_output 和 min_examined_row_limit

单靠调 long_query_time 无法解决日志爆炸，必须组合控制：

• 把 log_output 设为 FILE（而非 table），避免 slow log 写入 mysql.slow_log 表引发额外锁和复制延迟；
• 设置 min_examined_rows=1000（或更高），过滤掉那些“快但扫行多”的语句（如 select * FROM user LIMIT 1 扫百万行）；
• 开启 log_queries_not_using_indexes=OFF（默认关闭），否则索引缺失的简单查询也会进 slow log，数量远超预期。

验证和压测前务必检查 slow log 文件权限与磁盘空间

很多“日志爆炸”问题其实源于配置生效后没人管落地路径：

• 确认 slow_query_log_file 指向的目录有足够空间（建议单独挂载小容量 SSD 分区）；
• 检查 MySQL 进程对该文件是否有写权限（常见坑：/var/log/mysql/ 目录属主是 root，而 mysqld 以 mysql 用户运行）；
• 用 tail -f 实时观察日志增速，再结合 SHOW GLOBAL STATUS LIKE 'Slow_queries'; 对比计数是否合理；
• 如果用 mysqldumpslow 分析，记得加 -s t -t 10 防止因日志过大卡死。

真正麻烦的从来不是设成多少秒，而是没意识到 slow log 是诊断工具，不是归档系统——它只该存“值得人工看一眼”的那 0.1% 查询。