AI生成的SQL能直接运行吗？只读权限、执行计划与结果验算指南

AI生成的SQL可以提高取数效率，但不能默认直接运行。SQL即使是SELECT，也可能暴露敏感数据、扫描大量分区、造成连接资源紧张，或者在逻辑上悄悄算错。更稳妥的做法是把AI输出当作待验收代码，按以下顺序检查。

一、先固定输入信息和业务口径

提供给AI的内容应以完成任务所需的最小范围为准。优先给出必要的表结构、字段类型、主外键关系和脱敏样例，不要直接粘贴真实客户信息、账号、手机号或完整生产数据。同时说明数据库方言，例如使用哪一类数据库，以及日期函数、标识符引用和分页语法的要求。

还要写清楚业务口径：订单金额是否包含退款，取消订单是否排除，统计时区采用数据库时间还是业务所在地时间，按下单时间还是支付时间分组。口径不明确时，AI可能生成语法正确但不符合业务定义的查询。

二、不要只靠提示词禁止写操作

“只生成SELECT”或“禁止修改数据”的提示词只能减少意外，不能替代权限控制。执行前应优先使用独立的只读账户，或者在结构和样例数据足够接近的测试库中运行。账户还应遵循最小权限原则，仅能访问本次分析需要的库、表或视图。

只读权限也不等于没有风险。复杂关联、无条件聚合或大范围排序仍可能消耗CPU、内存和磁盘临时空间；查询结果本身也可能包含不应扩散的敏感信息。因此需要同时设置合理的超时、并发和资源限制，并确认结果输出范围。

三、逐项检查SQL逻辑

• 连接条件：确认JOIN使用了正确的键，检查一对多关系是否会把订单金额重复放大，避免缺少连接条件形成笛卡尔积。
• 聚合粒度：按月统计时，先明确是订单月、支付月还是退款月；检查GROUP BY字段是否与SELECT中的非聚合字段一致。
• NULL处理：SUM、COUNT和条件判断对NULL的行为不同。COUNT字段可能不统计NULL，而COUNT(*)统计行数，COALESCE也可能改变业务含义。
• 重复行：不要为了“去重”机械加入DISTINCT，应先找出重复产生的来源，并判断去重是否会掩盖真实记录。
• 日期边界：优先核对开始时间是否包含、结束时间是否排除，特别注意月末、闰年、夏令时以及数据库时区与业务时区的差异。

四、先看执行计划，再决定是否扩大范围

在目标数据库支持的前提下，先使用对应的EXPLAIN或等效命令查看访问路径、预计行数、连接方式和排序、聚合是否可能产生较大开销。不同数据库的执行计划命令和显示内容并不完全相同，不能把一种数据库的语法和结论直接套用到另一种数据库。

还要注意命令行为。有些数据库或配置下，EXPLAIN ANALYZE会实际执行查询，而不只是预估，因此不要未经确认就对生产数据运行。LIMIT只能限制返回行数，不能保证数据库少扫描数据；如果排序、聚合或连接发生在返回结果之前，底层仍可能处理大量记录。

五、用小样本和人工统计验算

先选一段范围较小、已知结果的数据进行验证。可以抽取少量订单，逐笔核对订单金额、退款金额、支付时间和状态，再与SQL结果比较。对于汇总结果，至少从总行数、去重后的订单数、金额合计和几个分组明细四个角度交叉验算。

例如验算按月统计订单金额时，先确认退款是否在订单金额中扣除，再统一时区并检查月初、月末记录。随后分别比较订单表单独汇总和加入支付、退款表后的结果。如果加入退款表后金额突然翻倍，通常要检查一笔订单是否匹配了多条退款记录；如果月份边界出现少量差异，则应回看时间字段、时区转换和结束日期条件。

六、形成可复用的验收清单

1. 确认输入资料已脱敏，且只包含必要表结构与样例。
2. 确认数据库方言、时间字段和业务统计口径。
3. 确认使用测试库或独立只读账户，并配置超时和资源限制。
4. 逐项检查连接、聚合、NULL、重复行和日期边界。
5. 查看适用的执行计划，确认分析命令是否会实际执行。
6. 用已知结果的小样本和人工统计交叉验证。
7. 验证通过后再逐步扩大时间范围，并保留SQL、口径和验算记录。

只有语法可执行并不代表结果可信。把安全权限、资源评估和业务验算放在同一条流程中，才能让AI生成的SQL从“看起来合理”变成“可以被审查和复核”。