AI SQL 改写边界：能改快，不代表可以自动上线
一、SQL 改写的风险不在语法，而在语义
AI 辅助 SQL 改写很诱人。给它一条慢 SQL、执行计划和表结构，它可以生成看起来更简洁的写法，甚至建议索引和 join 顺序。但数据库系统里最危险的不是语法错误，而是语义等价没有被证明。慢 SQL 至少结果是对的，错误的快 SQL 只会更快地产生坏数据。
因此 AI SQL 改写必须被限定在建议层。它可以提出候选改写、解释执行计划差异、指出潜在索引缺失，但不能直接替换生产 SQL。任何改写都要经过语义校验、结果抽样比对、执行计划对比、回归压测和灰度发布。数据库不接受“模型觉得应该一样”。
二、改写流程：候选生成和验证必须分离
flowchart TD
A[慢 SQL] –> B[执行计划与表结构]
B –> C[AI 生成改写候选]
C –> D[语法解析]
D –> E[结果等价校验]
E –> F[执行计划对比]
F –> G[压测与灰度]
G –> H[人工确认上线]
SQL 改写需要先定义允许范围。相对安全的方向包括谓词下推、去除无用列、拆分子查询、改写 IN 和 EXISTS、补充可用索引建议。高风险方向包括改变 join 类型、调整聚合粒度、修改去重逻辑、改变时间边界和隐式类型转换。后者必须非常谨慎。
还要注意业务语义。比如 left join 改成 inner join 在某些数据分布下结果相同，但语义已经改变；count(*) 改成近似计数可能适合看板，不适合账务；时间条件从闭区间改成半开区间可能影响边界数据。AI 不知道业务红线，工程系统必须知道。
三、验证实现：先比较结果，再比较耗时
下面是一个简化的校验思路。真实环境应使用影子库、采样参数和只读账号执行。
def compare_query(conn, old_sql, new_sql, params):
old_rows = conn.execute(old_sql, params).fetchall()
new_rows = conn.execute(new_sql, params).fetchall()
if len(old_rows) != len(new_rows):
return False, "row count mismatch"
old_hash = hash(tuple(old_rows))
new_hash = hash(tuple(new_rows))
return old_hash == new_hash, "hash compare finished"
简单 hash 比对不能覆盖全部情况，但它说明一个原则：结果正确性优先于性能。对于大结果集，可以按主键抽样、分桶校验、聚合校验和边界参数校验。不要只拿一组参数测试，SQL 的执行计划和结果风险常常随参数分布变化。
执行计划也要对比。改写后如果走了更低成本计划，但引入临时表、文件排序或全表扫描，就要继续分析。优化器成本估算不是绝对真理，线上统计信息和数据倾斜会让计划不稳定。
四、上线策略：慢慢放量，保留回滚
SQL 改写上线适合走灰度。可以先在只读查询、低风险接口或影子流量中验证。记录旧 SQL 和新 SQL 的耗时、扫描行数、返回行数、错误率和资源消耗。只有结果一致且性能稳定，才考虑扩大范围。
回滚要足够简单。新旧 SQL 应能通过配置切换，不要把改写直接硬编码到多个业务分支。数据库优化很少一劳永逸，统计信息更新、数据增长和索引变化都可能让曾经有效的改写失效。保留开关，是对未来的基本尊重。
最后，AI 生成的解释也要审查。模型可能把执行计划术语说得很像回事，但真实判断必须基于 EXPLAIN ANALYZE、慢日志、扫描行数和锁等待。数据库里没有玄学调优，只有证据链。
五、总结
AI SQL 改写可以提高分析效率，但不能越过语义等价、计划对比、压测和灰度。能改快不代表可以自动上线。把模型放在候选生成位置，把验证交给确定性工具和生产数据，SQL 优化才不会变成事故入口。
