SQL 慢查询日志的开启阈值与 long_query_time / log_queries_not_using_indexes 设置

不能，long_query_time设为0无法记录所有查询，因其受slow_query_log开关、log_output方式限制，且不记录被查询缓存命中或在解析/权限检查阶段失败的语句。 long_query_time 设为 0 真的能记录所有查询吗？ 不能，而且在 MySQL 5.7+ 和 8.0 中行为还不一样。设为 表示“记录执行时间 ≥ 0 秒的语句”，听起来像全量，但实际受 开关和 输出方式限制；更重要的是，它**不记录未真正执行的语句**（比如被查询缓存命中、或在解析/权限检查阶段就失败的语句）。 常见错误现象： 后日志里仍看不到某些明显慢的查询——很可能是它们被优化器提前剪枝，或走缓存没进执行器。 MySQL 5.6 及更早：设为 确实会记录所有执行完成的语句（含 这类毫秒级） MySQL 5.7+：默认以微秒精度计时， 表示“≥ 0 秒”，但内部有最小阈值（如 100 微秒），极短语句仍可能被跳过 必须同时开启 ，否则 设置无效 如果 ，查 表时要注意 字段是 DATETIME(6)，不是普通 DATETIME log_queries_not_using_indexes 开启后为啥日志爆炸？ 因为它不看执行时间，只看执行计划里有没有用到索引——哪怕一个 （无 WHERE、有主键）也会被记入，因为优化器可能选择全表扫描而非索引覆盖。 使用场景：适合上线前压测阶段快速发现缺失索引的查询，但**绝不能长期开着上生产**。 该开关对 、 、 等写操作同样生效 即使加了索引，如果用了函数（如 ）、或隐式类型转换（ 而字段是 INT），也会触发记录 MySQL 8.0.14+ 新增 ，可限制每分钟最多记几条，避免刷屏 注意：它和 是“或”关系——满足任一条件就会进慢日志 慢日志文件路径与权限问题怎么排查？ 最常卡在 MySQL 进程没有目标目录的写权限，或者配置了相对路径（如 ），结果日志被写进 mysqld 启动时的工作目录（通常是 或 ），而不是你预期的位置。 常见错误现象：配置改了、服务重启了，但 指向的路径下始终空空如也。 务必用绝对路径，例如 确认 MySQL 用户（如 进程所属用户）对该路径有 权限，且父目录可 （即 不够，得有 ） 如果用 ，记得检查 是否为空——它不限制慢日志，但很多人会混淆 Linux 下可用 快速验证权限 MySQL 8.0 的 performance_schema.events_statements_summary_by_digest 能替代慢日志吗？ 不能完全替代，但它是更细粒度的补充。慢日志记录原始 SQL 文本和耗时，而 按指纹聚合统计（如把 和 归为同一类），适合看“哪类查询最耗资源”，不适合定位单条异常语句。 性能影响：开启 并启用 消耗约 5%~10% CPU，比写磁盘的慢日志更轻，但内存占用随并发 SQL 类型线性增长。 要看到具体慢语句，需配合 （需开对应 consumer） 字段会截断，默认 1024 字节，长 SQL 的关键条件可能被砍掉 它不记录锁等待、IO 等外部延迟，只统计语句在 server 层的执行时间 如果你只关心“平均响应时间突增”，用这个比翻慢日志快得多；但要查某次超时的具体上下文，还是得靠慢日志+ general_log（谨慎开） 慢日志不是越细越好，关键是匹配你的诊断目标：调索引看 ，追故障看 阈值是否合理，查路径别忘了进程用户权限——这些点串起来才真正可控。