AI生成SQL最佳实践：执行计划校验与安全治理

大家好，我是数据库小学妹👋 我踩过的坑，你别再踩。

上个月，我们组差点出大事。一个同事让AI写了一条更新语句，看着挺对，跑完发现把整个状态字段都改了。语法没错，表名没错，就是忘了加WHERE。回滚回了一下午。

这不是个例。AI写SQL（也叫Text-to-SQL）越来越溜，但"语法对、结果错"的坑也越来越多。今天聊聊我是怎么在AI生成的SQL上线前，用五道关卡拦住的。这套流程跑下来，我们组好几个晚上不用加班了。

一、AI写的SQL，翻车就三种

先说AI生成的SQL最容易栽在哪，我复盘了半年的事故，归纳成三类。

第一类，字段幻觉。AI没见过真实的表结构，凭训练数据的印象编。表里没有的列，它敢写。一执行报错还是轻的，有时候会匹配到名字相近的列，悄悄跑偏。

第二类，性能灾难。语法完全对，执行计划烂到爆。隐式转换让索引失效，该走索引的走了全表扫描。小数据量没事，线上几千万行，一跑就卡死。

第三类，语义错误。这是最阴的。SQL能跑，结果错得离谱。忘了WHERE、JOIN方向写反、聚合口径不对。没人复核，数据就悄悄错了。

二、五道关卡，一道都不能少

针对这三类问题，我设计了五道审核关卡。每道拦一类，全过了才准上线。

第一道：结构预检。 先把SQL里的表名、字段名跟真实的表结构对一遍。AI编的字段，这里就露馅了。我用脚本自动比对information_schema，查表存不存在、字段在不在。

-- 检查SQL里用到的表和字段是否真实存在
SELECT table_name, column_name
FROM information_schema.columns
WHERE table_schema = 'appdb'
  AND (table_name, column_name) IN
      (('orders', 'product_name'), ('orders', 'user_id'));

第二道：执行计划校验。 这是最关键的。EXPLAIN一跑，走没走索引、扫描多少行，清清楚楚。我的红线是：type出现ALL全表扫描，或者rows估算超过阈值，打回重写。我自己的标准是：单表扫描行数估算超过10万行、或者涉及三张以上大表JOIN没有索引过滤的，一律打回。具体阈值根据你的业务数据量调整，但原则是“宁可严，不能松”。

EXPLAIN
UPDATE orders SET status = 'closed'
WHERE user_id = 12345 AND created_at < '2026-01-01';

-- 期望看到 type=range 或 ref，走索引
-- 如果看到 type=ALL，说明索引没生效，打回

第三道：高危操作拦截。 写死的规则，谁都不能破。没有WHERE的UPDATE和DELETE，一律拦。DROP、TRUNCATE这种破坏性语句，必须走双人审批。这些拦截不是靠关键字匹配，是通过解析SQL的AST抽象语法树来判断操作类型和条件，比字符串匹配准得多，能有效避免漏网和误拦。

第四道：灰度上线。 就算前几道都过了，也不直接全量。先放一小部分数据跑，或者先在只读副本上验证结果。确认没问题，再放量。AI的SQL，永远先小范围试。

第五道：审计追踪。 谁提交的SQL、哪条AI生成的、跑了多久、影响多少行，全记下来。出问题能回溯。审计日志这块，国产库里金仓KES这类做得很细，谁跑了什么SQL都有记录。真出事，能查到源头。

三、这套流程，拦住了什么

一起是字段幻觉。AI生成的SQL用了order_items表里不存在的product_name字段，第一道关卡就拦下了。一起是漏了WHERE的更新，第三道关卡挡在编译前。还有一起，JOIN方向写反，执行计划里扫描行数翻了十倍，第二道关卡发现了异常。

三次都没到生产，说明这套关卡是真有用的，不是摆设。

四、避坑清单

执行计划是底线，别只看结果对就放行。AI的SQL经常“结果对、性能烂”。小数据量跑得飞快，线上几千万行直接卡死。我要求所有上线的SQL，必须过EXPLAIN，type出现ALL就打回。这条红线，一次都没破过。我见过最典型的一次，AI生成的SQL在小数据量测试库跑了0.1秒，结果对得上。但EXPLAIN一看，走的全表扫描。上了生产，5000万行数据，直接卡死。如果当时没看执行计划就放行，又得熬一个通宵。 所以我现在不管多急，EXPLAIN必须跑。

高危操作拦截写死，别给任何人开例外。没有WHERE的UPDATE、DELETE，DROP、TRUNCATE，这些必须拦。我见过最惊险的一次，AI生成的删除语句只差一秒就执行了，被拦截规则挡下来。例外开一次，防线就废了。

AI的SQL永远先小范围试。就算审核全过，也别直接全量。先放一小批数据验证，或者先在只读副本跑。我吃过亏，审核过了直接全量，结果一个边界条件没覆盖，还是出了事。小范围试，成本低，安心。

我的判断

AI写SQL这事，挡是挡不住的。2026年的行业报告显示，96.5%的组织已经允许AI与生产数据库交互，它会越来越普遍，这是趋势。DBA能做的，不是不让用，而是让"用了不出事"。

把五道关卡的防线强度排个序：高危操作拦截最稳，规则写死就一定能拦；执行计划校验居中，判断全表扫描看type就能定性，但阈值需要经验；灰度上线最不可替代，前四关全过也可能在真实业务场景翻车；结构预检和审计追踪一前一后，一个防在前，一个兜在后。每一关都有它拦不住的东西，所以才要五道叠起来。

具体落地的时候，最容易出问题的不是执行计划校验，而是灰度上线被跳过。审核过关了就急着全量推，觉得“应该没问题”。我见过最典型的翻车，是AI生成的SQL结构对了、执行计划对了、高危拦截也过了，放量之后才发现一个边界条件没覆盖，因为测试数据里没有那种情况，AI也没考虑到。灰度的作用就是挡住这种“逻辑对但业务场景不全”的坑。前四关拦的是“能不能跑”，灰度拦的是“跑得对不对”。后者比前者更难自动化。

将来AI生成SQL的治理，会从“人审”变成“规则审”加“人抽查”。规则能拦的，机器拦。需要判断的，人来定。分工清楚，才扛得住AI写SQL的量。

你让AI写的SQL直接上过生产吗？翻过车吗？评论区聊聊。

我是数据库小学妹，帮你少走弯路少踩坑，咱们下篇见👋