AI SQL 变更闭环：建议生成之后，还要有人负责回滚

AI SQL 变更闭环：建议生成之后，还要有人负责回滚

一、AI 建议不能直接变更生产

AI 可以根据慢查询、执行计划和索引信息生成 SQL 改写建议，但建议不是变更。数据库变更的核心问题不是“这条 SQL 能不能更快”，而是“它失败时谁承担后果，怎么回滚，怎么证明影响可控”。

SQL 改写可能改变锁范围、返回顺序、扫描路径、临时表使用和事务耗时。自动生成建议如果缺少闭环，很容易从优化工具变成生产事故入口。

二、闭环从证据开始

flowchart TD A[AI SQL 建议] --> B[风险评分] B --> C[回放验证] C --> D[灰度发布] D --> E[指标观测] E --> F[回滚预案]

每条建议都要绑定证据：原 SQL、改写 SQL、执行计划差异、样本数据量、预估影响表、相关索引和验证结果。没有证据的“预计提升 30%”不应该进入变更流程。

sql_change_record: original_sql: required rewritten_sql: required explain_diff: required rollback_sql: required owner: required

AI 生成的是候选方案，工程系统要负责审计和落地。

三、回放验证要覆盖长尾

只拿一两条参数验证，会漏掉数据分布问题。SQL 的性能经常和参数选择高度相关：某个用户数据少很快，另一个用户数据多就全表扫。回放平台应抽取历史参数分布，覆盖高频、低频和极端值。

EXPLAIN ANALYZE SELECT * FROM orders WHERE user_id = ? AND status = ? ORDER BY created_at DESC LIMIT 20;

验证时还要比较返回行数、排序稳定性、执行时间、扫描行数、临时表和锁等待。只看平均耗时，会掩盖长尾变差。

四、灰度和回滚必须前置

AI SQL 改写上线前，要定义灰度比例、监控指标和回滚触发条件。比如 P99 延迟上升、错误率增加、主从延迟扩大、锁等待升高，都应自动阻断扩量。

rollout_guard: p99_latency_increase: 0.15 error_rate_increase: 0.01 lock_wait_threshold_ms: 200 replica_lag_seconds: 10

回滚不是上线失败后的临时动作，而是变更单的一部分。能否快速恢复原 SQL、原索引或原执行路径，决定了这次优化能不能被批准。

最后，变更结束后要做复盘。AI 建议是否命中真实瓶颈，风险评分是否准确，灰度指标是否足够敏感，都要回写到规则和模型中。

还要记录影响范围。一次 SQL 改写可能被多个接口、定时任务或报表复用，如果只按单个调用点验收，很容易漏掉低频路径。上线前应从 SQL 指纹反查调用方，把核心接口、后台任务和离线作业分开评估。

impact_analysis: sql_fingerprint: required api_callers: required batch_jobs: required report_queries: required

如果改写涉及分页、排序或聚合，还要做结果语义比对。性能变快但返回顺序不稳定，或者聚合口径发生变化，都不能算优化成功。

最后，负责人要明确到人。AI 可以生成建议，平台可以执行流程，但变更判断必须有人签字。生产数据库不接受“模型觉得可以”这种责任链。

五、总结

AI SQL 变更闭环要包括证据、风险评分、回放验证、灰度观测和回滚预案。

建议生成不是终点。数据库优化能上线，靠的是可控变更，而不是漂亮解释。