线上慢SQL治理需建立规范、工具链与运营闭环：上线前硬卡SQL准入，线上实时监控预警，根因分析结合执行上下文，长效治理通过认领制、索引管理、质量评分及规范反哺实现持续优化。
线上慢SQL治理不是靠一次优化就能解决的事，核心在于建立可落地的规范 + 配套自动化工具链 + 持续运营机制。重点不在“怎么改一条SQL”，而在于“怎么不让慢SQL上线”“怎么快速发现和定位”“怎么避免反复发生”。
一、上线前卡点：SQL准入规范必须硬约束
多数慢SQL源于开发阶段缺乏约束。不能依赖上线后人工Review，要嵌入研发流程：
- 禁止SELECT *，必须明确字段列表——减少网络传输和内存消耗，也便于后续索引覆盖判断
- WHERE条件必须命中有效索引——建表时同步定义好查询场景的联合索引，CI/CD阶段用SQL静态分析工具（如SOAR、SQLAdvisor）自动检查执行计划是否走索引
- 单表查询结果集限制默认5000行——配合分页逻辑（推荐cursor分页），避免OFFSET深分页导致全表扫描
- 禁止在WHERE中对字段做函数操作或隐式类型转换——例如WHERE DATE(create_time) = '2024-01-01'会失效索引，应改写为create_time BETWEEN '2024-01-01 00:00:00' AND '2024-01-01 23:59:59'
二、线上实时监控：从“被动救火”转向“主动预警”
慢SQL不是等业务投诉才处理，要靠数据驱动：
- 统一采集层：MySQL开启slow_query_log（long_query_time ≤ 1s），用pt-query-digest或Percona Toolkit归档分析；或接入阿里云DMS、腾讯云DBbrain等平台自动解析
- 分级告警策略：按响应时间分三级（>1s / >5s / >30s），>5s的SQL自动推送至企业微信/钉钉群，并关联负责人
- 聚合看板：按服务名、接口路径、数据库实例、SQL指纹（参数脱敏后的标准化模板）统计TOP耗时SQL，支持下钻查看执行计划与历史趋势
三、根因定位：别只看EXPLAIN，要结合真实执行上下文
很多同学看到“type=ref”就以为没问题，其实关键要看实际扫描行数和临时表使用情况：
- 关注key_len是否合理：比如联合索引(a,b,c)，WHERE a=1 AND b>10，key_len应为a+b长度；若只显示a的长度，说明b未生效
- Extra字段是重点：“Using filesort”“Using temporary”“Using join buffer”都意味着性能瓶颈，需结合数据分布判断是否需要调整索引或改写SQL
- 查真实执行计划而非预估：用EXPLAIN FORMAT=JSON或EXPLAIN ANALYZE（MySQL 8.0.18+）获取实际扫描行数、IO次数、是否触发磁盘临时表等
- 注意并发影响：单条SQL在低负载下很快，高并发下可能因锁等待、Buffer Pool争用变慢，需结合performance_schema中的events_statements_history_long分析
四、长效治理：建立闭环机制，避免问题复发
治理效果能否持续，取决于有没有闭环：
- 慢SQL认领制：每条超阈值SQL自动创建工单，绑定服务Owner，要求48小时内反馈优化方案并验证效果
- 索引生命周期管理：定期用sys.schema_unused_indexes识别长期未被使用的索引，避免冗余索引拖慢写入
- SQL质量评分卡：基于执行时间、扫描行数、是否走索引、是否含子查询等维度打分，纳入研发交付质量考核
- 定期反哺规范：每月汇总TOP慢SQL模式（如“LEFT JOIN无ON条件”“IN子查询未加LIMIT”），更新团队SQL编写手册和IDE插件规则
