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