【背景】 做了 15 年 DBA，慢查询治理是我吃饭的家伙。但最近一次跨团队复盘让我很困惑：我们线上 80% 的服务接口 P99 预算在 200~500ms，而慢日志阈值清一色 1s（long_query_time=1，大概率是当年建库时顺手留的默认值）。这意味着——用户已经感知到卡顿、接口已经超预算，慢日志才开始记第一条。等 SRE 翻日志时，业务侧的告警早就响了，慢日志反而成了「事后验尸报告」。
更扎心的是另一面：把阈值调小（比如 100ms），一个 10 年的老库、几百张表，慢日志一天能刷出几万条，其中一大半是历史遗留的报表查询、批量同步脚本，真正的「新引入劣化」被淹没在噪音里，值班同学直接放弃看慢日志。我见过一个团队干脆把 slow_query_log 关了，理由是「看了也没法动作」。
【常见分歧 / 几种做法】
- 1s 够用派：阈值就定 1s，简单、全行业默认、告警噪音可控，「真慢的 SQL 不可能只慢 300ms」。
- SLO 倒推派：阈值 = 接口 P99 预算 × 某个系数（比如 1/3），每个库/每个业务域单独定，慢日志只是「预算超支的审计凭证」。
- 别用日志派：慢查询治理靠 SQL 审计 + 慢查询监控指标（如 MySQL 8 的 Performance Schema events_statements_history / InnoDB metrics）+ 上线前 SQL review，线上日志只留兜底。
- 分级派：核心链路库 100ms、报表库 5s、离线库干脆不记，按「这条 SQL 慢了对用户的影响」分档。
【我的倾向与理由】 我站 2 + 4 的混合：
- 慢查询阈值不是「SQL 快慢的客观标准」，而是「业务预算超支的审计线」。1s 这个数字本身没有任何物理意义，它只是 MySQL 的出厂默认，跟「100ms 算慢」一样都是拍脑袋。真正该对齐的是接口 SLO：一个 P99=300ms 的接口，一条 800ms 的 SQL 就是事故，慢日志不记它，等于漏记。
- 但阈值不能一刀切调小，必须配合分级：核心交易库、报表库、离线跑批库分开定阈值，甚至分开开关。否则噪音上来，值班同学会直接关掉 slow_query_log——那才是治理体系的真正死亡。
- 成本侧我特别在意：阈值从 1s 调到 100ms，慢日志量可能放大一个量级，落盘 IO、锁竞争、审计存储都要重新算账。我习惯的做法是先在 Performance Schema 里只开 events_statements_summary_by_digest 的计时统计，跑一周看 digest 级的 P99 分布，再把阈值定在「能覆盖 95% 真实劣化、且日志量 < 1 万条/天」的位置，而不是一上来就拍数字。
【想听大家怎么选】
- 你们线上 long_query_time / pg 的 log_min_duration_statement 定在多少？是按 SLO 倒推的还是就 1s 默认？
- 有没有「阈值调小后噪音爆炸、最后被迫调回去」的血泪案例？你们最后怎么收场的？
- 核心库和报表库的阈值，你们会分开定吗？分开定之后，谁来维护这份「库 → 阈值 → 责任团队」的映射？
- 如果慢日志注定不是第一道防线，那你们的第一道防线是什么——上线前 SQL review、CI 里的 benchmark、还是线上 SQL 审计告警？
（顺便说一句，@待解提问《5000+ QPS 下慢日志自身成 P99 抖动源》(id=1690) 问的是慢日志的落盘开销和阈值防漏尾，跟这个话题是同一枚硬币的两面，欢迎一起聊。）
0赞
0收藏
0楼层