慢 SQL 治理是标准化、可复用、可持续的体系化工程，需围绕“发现准、定位清、优化稳、防控早”构建监控、分析、优化、预防闭环。
慢 SQL 治理不是临时救火，而是需要标准化、可复用、可持续的体系化工程。核心在于“发现准、定位清、优化稳、防控早”，形成从监控、分析、优化到预防的闭环。
一、建立统一的慢 SQL 识别标准与采集机制
没有统一标准，就无法规模化治理。建议明确三类阈值：
- 基础慢 SQL 阈值 ：数据库默认慢日志阈值（如 MySQL 的 long_query_time=1s），作为兜底采集依据；
- 业务分级阈值 ：按接口 / 模块重要性设定差异化标准（如核心支付接口 >200ms 即告警，后台报表可放宽至 5s）；
- 资源敏感阈值 ：不只看耗时，同步采集 CPU、IO、锁等待、扫描行数等指标，对“快但伤库”的 SQL（如全表扫描 + 高并发）也纳入治理范围。
采集需覆盖全链路：数据库慢日志 + 应用层 SQL 埋点（如 MyBatis 拦截器）+ APM 工具（SkyWalking、Pinpoint）三方交叉校验，避免漏报或误判。
二、结构化 SQL 分析流程：从执行计划到业务语义
拿到慢 SQL 后，拒绝“凭经验改写”。推荐四步归因法：
- 看执行计划（EXPLAIN）：重点确认是否走索引、是否有 Using filesort/Using temporary、key_len 是否合理、rows 预估是否严重偏离实际；
- 查数据分布 ：explain 结果中 rows 不准？立刻查对应字段的 cardinality、数据倾斜情况（如 status=‘待处理’占 95%）；
- 读业务上下文 ：该 SQL 在什么场景触发？参数是否固定？是否在循环中调用？有没有分页深翻（offset 过大）？
- 压测验证假设 ：修改前先用相同数据量 + 真实参数复现，改写后对比 QPS、耗时、IO 开销变化，不唯耗时论成败。
三、分层优化策略：索引、SQL、架构协同推进
单一手段易失效，需按优先级分层落地：
- 索引层（最快见效）：优先覆盖高频慢查询的 WHERE+ORDER BY+JOIN 条件组合；避免冗余索引；注意索引失效场景（函数操作、隐式类型转换、LIKE 前置通配）；
- SQL 层（最常被忽视）：禁止 SELECT *；拆分复杂联合查询为多次简单查询（尤其跨库 / 跨服务时）；分页改用游标（cursor-based）替代 OFFSET；IN 列表长度超 500 时考虑临时表或批量处理；
- 架构层（治本之策）：读写分离下避免从从库查强一致性数据；高频统计类 SQL 迁至离线计算或实时 OLAP 引擎（如 Doris、StarRocks）；冷热数据分离，历史库归档；
四、构建可持续防控机制：卡点 + 度量 + 沉淀
防止问题反复发生，关键在流程嵌入和知识复用：
- 上线前卡点 ：CI 阶段集成 SQL 审核工具（如 Yearning、Archery、SQLE），自动拦截无索引查询、大表 DDL、高危语法；
- 效果可度量 ：定义核心指标——慢 SQL 数量周环比下降率、平均响应时间降幅、索引命中率提升值，并纳入 DBA/ 研发 OKR；
- 案例库沉淀 ：每例治理完成的 SQL，记录原始问题、执行计划片段、优化动作、压测对比、适用场景标签（如“分页优化”“关联字段类型不一致”），供团队检索复用。
慢 SQL 治理不是一次专项，而是数据库健康度的日常体检。标准流程立得住，体系才能跑得久。
