慢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治理不是一次专项，而是数据库健康度的日常体检。标准流程立得住，体系才能跑得久。
