mysql慢查询日志未记录慢sql的首要原因是slow_query_log未开启，必须先设slow_query_log=on，再配合long_query_time阈值、权限、路径及log_output=file等配置才能生效；long_query_time单位为秒，支持微秒级但需版本支持且不向上取整，差1纳秒也不记录。
直接说结论：MySQL慢查询日志本身不支持“只记录耗时超过1秒的语句”这种动态阈值过滤，long_query_time 是全局或会话级的硬性开关，但它的生效逻辑和精度容易被误解，导致你查不到本该出现的慢SQL。
为什么设置 long_query_time = 1 后还是看不到慢SQL？
常见错误是把 long_query_time 当成“只要执行时间 > 1s 就记录”，实际上它受两个关键因素影响：
-
long_query_time的单位是秒，但**默认只保留小数点后1位**（MySQL 5.7+ 可设为微秒级，但需显式启用）；比如实际耗时 1.04s，在旧版本会被截断为 1.0s，不满足 >1.0 条件 - 该阈值对**未使用索引的查询（
log_queries_not_using_indexes开启时）也生效**——即使执行时间 - MySQL 8.0+ 默认关闭
log_output = FILE，若你只配置了变量但没确认输出方式，日志根本不会写到文件
如何确保 1 秒以上 SQL 真正落盘到日志？
必须同时校准三处配置，并验证是否生效：
MySQL（Linux）
下载
MySQL 9.6.0是面向Linux平台的2026年创新版本，核心架构迎来重大革新。其将外键约束与级联操作从InnoDB引擎层上移至SQL层，确保所有数据变更均被完整记录至Binlog，彻底解决了CDC（变更数据捕获）与主从复制中的数据不一致难题。此外，该版本引入container_aware启动选项以原生适配容器环境，并对审计日志进行了组件化重构，为追求极致数据一致性与云原生体验的开发者提供了全新选择。
- 在
my.cnf或启动时动态设置：long_query_time = 1.0（显式带小数点，避免整型截断） - 开启日志输出：
slow_query_log = ON+slow_query_log_file = /var/lib/mysql/mysql-slow.log - 强制记录未走索引的语句（可选但推荐）：
log_queries_not_using_indexes = ON，否则可能漏掉低效但快于 1s 的全表扫描 - 重启 MySQL 或执行
SET GLOBAL slow_query_log = ON后，用SELECT SLEEP(2)测试是否真有日志生成
查看日志时为什么找不到预期的 SQL？
慢日志不是实时刷新的，也不是每条都带完整上下文：
- 日志默认**按 query 开始时间排序，不是结束时间**；高并发下多条语句交织，靠时间戳定位容易偏差
- 默认不记录参数化后的值（如
WHERE id = ?），只记录原始语句模板；如果应用用 ORM 拼接 SQL，日志里看到的是带占位符的语句，看不出实际数据分布 - MySQL 5.7+ 支持
log_slow_extra = ON，可追加query_time、lock_time、rows_examined等字段，不开启的话只能靠肉眼算时间差 - 日志文件权限问题常被忽略：MySQL 进程用户（如
mysql）必须对slow_query_log_file路径有写权限，否则静默失败
最易被忽略的一点：MySQL 的 long_query_time 判断发生在语句执行**结束后**，但网络延迟、客户端接收时间、存储引擎锁等待等都不计入这个值——你看到的 1.2s，可能只是优化器+执行器耗时，而真正卡住用户的可能是后续的网络传输或连接池排队。定位瓶颈得结合 SHOW PROCESSLIST 和性能模式（performance_schema）一起看，不能只盯慢日志。
