默认long_query_time=10在生产环境几乎没用，因用户对超1秒延迟已明显感知，且未走索引、扫描大量数据的“快但有害”查询根本不会触发该阈值；线上建议设为0.5秒，核心链路可压至0.1秒，并需配合log_queries_not_using_indexes和min_examined_row_limit精准捕获隐患。
为什么默认的 long_query_time=10 在生产环境几乎没用
MySQL 默认值是 10 秒，但真实业务中，接口超 1 秒用户已明显感知卡顿，电商场景下 0.5 秒延迟就可能影响转化率。更关键的是，很多“不慢但有害”的查询——比如未走索引、扫描百万行只返回几条——根本不会触发默认阈值。
-
long_query_time必须下调：线上建议设为0.5（500ms），核心交易链路可压到0.1（100ms） - 微秒级支持：MySQL 5.7+ 允许小数，
0.001表示 1 毫秒，适合深度排查索引缺失问题 - 注意会话级覆盖：执行
SET long_query_time = 0.1只影响当前连接，全局生效必须用SET GLOBAL long_query_time = 0.1 - 临时调成
0风险极高：会记录所有 SQL，磁盘几小时内爆满，改完务必立刻恢复
log_queries_not_using_indexes 开还是不开？
这个参数不是“要不要记录慢查询”，而是“要不要记录所有未走索引的查询”——哪怕它只花了 0.002 秒。它的价值在于提前暴露隐患，比如某条 WHERE 条件字段没建索引，当前数据量小看不出问题，等涨到千万级直接拖垮服务。
- 测试/预发环境：强烈建议设为
ON，配合EXPLAIN扫描全表的语句 - 生产环境：视负载而定。高并发 OLTP 系统开启后日志量暴增，建议搭配
min_examined_row_limit = 1000（只记录扫描超 1000 行的无索引查询） - 不要长期开着还不管：它产生的日志和
long_query_time日志混在一起，不及时分析等于白开
日志路径和输出方式选 FILE 还是 TABLE？
默认是 FILE，写入磁盘；TABLE 方式把日志存进 mysql.slow_log 表，本质是 CSV 引擎表，支持 SQL 查询但性能差、不支持事务。
-
FILE更稳妥：顺序写入，I/O 压力小；配合mysqldumpslow工具快速聚合，比如mysqldumpslow -s t -t 5 /var/log/mysql/slow.log -
TABLE仅适合低频调试：想查“最近 1 小时哪些 IP 贡献最多慢查询”，可直接SELECT * FROM mysql.slow_log WHERE start_time > NOW() - INTERVAL 1 HOUR - 路径权限必须检查：
slow_query_log_file指向的目录，MySQL 进程用户（如mysql）要有写权限，否则日志静默失效 - 别和数据目录放一起：
/var/lib/mysql/是热点路径，日志写入会加剧 I/O 竞争，推荐独立挂载盘如/var/log/mysql/slow.log
动态开关和配置文件，哪个更可靠？
动态设置（SET GLOBAL）见效快，但 MySQL 重启就丢；配置文件（my.cnf）一劳永逸，但改错可能导致启动失败。
- 上线前必须写进
my.cnf：尤其slow_query_log=ON和slow_query_log_file，避免重启后监控断档 - 动态调参只用于临时诊断：比如怀疑某类查询突然变慢，临时把
long_query_time降到0.01抓 10 分钟样本 - 改完配置文件务必验证：
mysqld --defaults-file=/etc/my.cnf --validate-config（MySQL 8.0+），或至少mysqld --verbose --help | grep slow看是否加载成功 - 别信
SHOW VARIABLES的全部结果：有些变量（如long_query_time）在会话里显示的是会话值，得用SHOW GLOBAL VARIABLES看真实全局值
真正容易被忽略的，是日志本身的质量控制——阈值设太低，日志爆炸；设太高，漏掉关键问题；开了 log_queries_not_using_indexes 却不看 Rows_examined 字段，等于只拿到半截线索。优化不是调几个参数就完事，而是让每条日志都指向可落地的动作：加索引、改写 SQL、拆分大表。
