设为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% 查询。
