SQL稳定性需在开发、测试、上线、运行四阶段持续嵌入约束与反馈；审核须前置至IDE和CI阶段，集成轻量规则与EXPLAIN检查；慢查询归因需综合lock_time等多维度指标；索引变更需影子库验证与流量观察；应用层缓存失效可能压垮SQL稳定性。
SQL 稳定性不是靠一次治理或一个工具能解决的，它需要在开发、测试、上线、运行四个阶段持续嵌入约束和反馈机制。
SQL 审核必须前置到 IDE 和 CI 阶段
等 SQL 到线上才拦截，已经晚了。真正有效的审核要发生在开发者敲完 SELECT 的那一刻。
- 在 VS Code 或 IntelliJ 插件中集成轻量规则（如禁止无
WHERE的UPDATE/DELETE、检测全表扫描风险的LIKE '%xxx'） - CI 流水线里跑
EXPLAIN模拟执行计划，对扫描行数超10000或出现type=ALL的 SQL 直接失败构建 - 避免把所有规则塞进数据库代理层——延迟高、误报多、开发者感知弱
慢查询归因不能只看 execution_time
很多“慢查询”实际卡在锁等待、磁盘 IO 或连接池耗尽，单看执行时间会误导优化方向。
- 采集时必须同时记录
lock_time、rows_examined、tmp_tables、created_tmp_disk_tables - 对
state=Waiting for table metadata lock这类错误码单独告警，它往往意味着 DDL 与查询冲突，而非 SQL 本身问题 - 用
pt-query-digest聚合时，按--group-by fingerprint而非原始 SQL，否则参数化差异会让同一类问题分散不可见
索引变更必须配套回滚验证和流量观察
加索引不等于性能提升，尤其在写多读少或存在冗余索引的场景下，可能反而拖慢 INSERT 和 UPDATE。
- 上线前用影子库回放真实流量，对比
QPS、avg_latency、innodb_row_lock_waits - 索引命名强制带业务标识，例如
idx_order_user_status_created，避免后期无法判断用途而不敢清理 - 监控新增索引 72 小时内的
Handler_read_next和Handler_read_rnd_next变化，突增说明索引未被有效利用
最常被忽略的是应用层缓存与 SQL 稳定性的耦合：当缓存失效风暴触发大量相同 SQL 请求，再稳定的执行计划也会被并发压垮。这要求 DBA 和后端开发必须共享慢查询 TopN 和缓存击穿日志，而不是各自看各自的指标。
