long_query_time不是设小就能捕获所有慢SQL，它仅对MySQL内核执行耗时超阈值的语句生效，且受会话级作用域、版本精度限制（5.7及以前向下取整）、锁等待不计入Query_time、log_output配置及云服务覆写等影响。
直接说结论：long_query_time 不是“只要设小就能抓到所有慢 SQL”，它只对执行时间超过该值的语句生效，且受会话级设置、精度限制、事务上下文和日志输出方式影响；设得太低（比如 0.1）反而可能漏掉锁等待或网络延迟导致的真实慢查询。
为什么 long_query_time 设成 1 却没记录明显卡顿的查询？
常见现象是：手动执行 SELECT * FROM orders WHERE status = 'pending' LIMIT 1000 明显卡顿，但慢日志里没有这条记录。原因有三：
-
long_query_time默认单位是秒，且只计算 SQL 在 MySQL 内核中实际执行耗时（不含网络传输、客户端解析、连接建立等），锁等待时间（Lock_time）单独统计，不计入Query_time； - 该参数是会话级变量，你用
SET SESSION long_query_time = 1设置后，仅对当前连接有效；新连接仍用全局值，需确认是否已执行SET GLOBAL long_query_time = 1； - 如果
log_output设为TABLE（即写入mysql.slow_log表），而该表是 CSV 引擎或未启用slow_query_log全局开关，日志根本不会落地。
如何安全地调低 long_query_time 并验证生效？
不要一上来就设 0.1 —— 这会导致日志暴增，尤其在高并发 OLTP 场景下。推荐分步操作：
- 先查当前值：
SHOW VARIABLES LIKE 'long_query_time'，注意返回的是 float 类型（如 10.000000），不是整数； - 临时调低测试（无需重启）：
SET GLOBAL long_query_time = 2.0（建议从 2 开始，不是 1）； - 强制触发一条可控慢查询验证：
SELECT SLEEP(2.1)，再检查日志文件或SELECT * FROM mysql.slow_log ORDER BY start_time DESC LIMIT 1； - 若用文件输出，确认
slow_query_log_file路径可写，且 MySQL 进程有权限（常见坑：路径父目录不存在或 SELinux 拦截）； - 避免在生产环境长期设低于 0.5，否则
log_queries_not_using_indexes+ 低阈值极易撑爆磁盘。
long_query_time 和 min_examined_row_limit 的配合陷阱
很多团队想“只抓又慢又扫全表的 SQL”，于是同时设：
SET GLOBAL long_query_time = 1.0; SET GLOBAL min_examined_row_limit = 1000;
结果发现 SELECT id FROM users WHERE created_at > '2025-01-01' 扫了 5000 行却没进日志——因为 min_examined_row_limit 是“扫描行数下限”，但它的判断依据是优化器预估的 rows_examined，不是实际扫描数；如果走了索引，即使最终查出万行，rows_examined 可能只报几百。真正可靠的方式是关掉这个参数，改用 log_queries_not_using_indexes = ON 配合 long_query_time 组合筛选。
云数据库上 long_query_time 可能被服务商覆盖
阿里云 RDS、腾讯云 CDB 等托管服务中，long_query_time 常被控制台配置项屏蔽。即使你执行 SET GLOBAL long_query_time = 0.5，几秒后查回来仍是 1.0 —— 因为服务商后台定时覆写配置。此时必须通过控制台「参数模板」修改并应用，或使用其提供的审计日志替代方案。本地部署 MySQL 才完全可控。
最易被忽略的一点：MySQL 8.0.14+ 版本起，long_query_time 支持毫秒级（如 0.35），但 5.7 及更早版本只支持秒级浮点，设 0.35 会被截断为 0，导致所有查询都记为慢查询。务必先确认版本再设小数。
