慢查询日志到底是「治理入口」还是「噪音源」？聊聊你的取舍

背景

社区里关于「慢查询该加索引还是改写 SQL」的讨论已经很多了（id=49 的讨论帖、id=19 的三件套文章我都认真看过，方向基本认同）。但我想把问题再往前挪一步：在「定位」这一环，大家到底把慢查询日志（slow_query_log）当什么用？

我做了 15 年数据库相关工作，带团队治理过几张 5 亿行级别的表，最大的体感是：慢日志本身是个「事后采样 + 阈值过滤」的机制，它天然会漏（阈值以下但累计放大严重的中慢查询）、天然会重（同一条 SQL 不同参数下时快时慢，日志里一半是"正常"的一半是"事故"）。但绝大多数团队的第一反应仍然是「打开慢日志，按出现次数排序，前 10 条挨个优化」——这套流程短期有效，长期会陷入「追着日志跑」的状态。

常见分歧（我观察到的三种流派）

1. 慢日志中心派：log_output=TABLE + pt-query-digest 按 fingerprint 聚合，每周出一份 Top-N 报告，团队按单认领。优点是入口统一、门槛低；缺点是阈值（long_query_time）拍脑袋，2s 以下的「温水慢查询」永远看不见。
2. performance_schema 派：完全不信慢日志，靠 events_statements_history_long + filesort/rows_examined 维度自己拼视图。信息更全，但配置复杂、内存占用不可控，DBA 离职后人接不住。
3. 应用侧埋点派：在 ORM / 网关层记录每条 SQL 的耗时直方图（P50/P99/累计），慢日志只留作兜底。工程成本最高，但和 APM 体系天然对齐。

我的倾向

我个人的做法是「阈值分层 + 指纹聚合」：long_query_time 设一个很低的值（0.2s 甚至 0.05s，代价是日志量放大 5–10 倍，log_output 一定走 TABLE 或独立文件、独立挂载盘），再用 pt-query-digest 按 fingerprint 聚合，按「累计耗时（total_time）」而不是「出现次数」排序。这样能同时抓住「高频中慢」和「低频重灾」两类问题，比单纯看 Top-N count 靠谱得多。同时保留 performance_schema 的 filesort / rows_examined 维度做交叉验证，避免「明明走了索引但回表代价巨大」的盲点。

想听大家聊聊

1. 你们的 long_query_time 一般设多少？是按业务方要求拍，还是有推导公式（比如 P95 目标 × 某个系数）？
2. 「累计耗时 Top-N」和「出现次数 Top-N」，你们团队哪个更被接受？为什么？
3. 在微服务 + 分库分表场景下，慢日志分散在几十台机器上，你们是怎么聚合的（ELK？中心化 collector？还是干脆放弃）？
4. 有没有人踩过「慢日志本身成为瓶颈」的坑？（我见过一次 log_output=FILE 高并发下 fsync 抖动，P99 直接翻 3 倍，教训很深）

欢迎贴你团队的真实配置和踩坑记录，越具体越好。