浏览 AI 知识库
让 AI 写 SQL 时怎样限制范围并先做只读验证
让 AI 写 SQL 时，最危险的不是语法错误，而是语句正确地改错了数据。先用只读查询预览对象、主键和影响行数，再考虑审批执行。
按实际操作顺序推进
每完成一段就检查当前输出，确认结果符合预期后再继续。
删除“重复客户”之前，先证明这些记录真的重复
让 AI 写“删除重复客户”的 SQL，它根据姓名去重并准备执行 DELETE；同名客户实际属于不同公司，影响行数也没有预览。
- 只读预览和影响行数已确认
- 业务主键定义由负责人批准
- 写操作仍处于人工审批之后
动手前，把材料和不能改的部分定下来
| 需要确认 | 本例内容 |
|---|---|
| 现有材料 | 表 `customers` 含 customer_id、company_id、email、name；重复定义必须是同 company_id 与规范化 email。 |
| 不能越过的边界 | 先只读查询和小样本；写操作必须显式事务、审批与备份；表名和 WHERE 不确定时停止。 |
| 要交付的结果 | 只读预览、影响行数与审批记录 |
AI 写 SQL 注意事项，从“固定目标和范围”开始做
固定目标和范围
写要找或修改的精确对象、时间窗、租户和排除条件，确认主键与唯一约束。
先生成 SELECT
用与计划写操作完全相同的 WHERE 和 JOIN 预览主键、旧值、新值候选和总行数。
检查执行计划与锁
在合适环境评估索引、全表扫描、事务大小和并发影响，避免一次处理未知规模。
准备备份和事务
选择可恢复方式、批次、审计表和回滚 SQL；数据库不支持所需事务语义时重新设计。
批准后执行并复核
由责任人确认目标、影响行数和窗口；执行后重跑核对查询并保存日志。
先列出将被更新的 37 个主键，再讨论 UPDATE
| 步骤 | 实际输入 | 输出 | 批准标准 |
|---|---|---|---|
| 目标 | tenant_id=acme，status=pending，created_at<2026-09-01 | 范围条件和排除条件 | 责任人确认租户和时间窗 |
| 预览 | 同一 WHERE 的 SELECT id, status | 37 个主键、旧值和计数 | 数量与业务预期一致 |
| 计划 | EXPLAIN 与锁/索引观察 | 执行计划、耗时和影响 | 无未知全表锁或超时 |
| 执行 | 受控事务/批次和备份 | 实际更新行数和日志 | 与预览一致，异常可回滚 |
| 复核 | 再次 SELECT 与业务报表 | 新状态和审计记录 | 随机抽样通过 |
租户、日期和数量为演示输入；生产写操作必须由当前负责人确认。
让 AI 写 SQL 前，先限定只读范围和样例结果
AI适合起草查询与解释执行计划，不应直接操作生产库。
可复制使用
让 AI 写 SQL 前，先限定只读范围和样例结果
我需要一条只读 SQL 来回答指定问题。请先检查数据结构和口径，不能连接或执行数据库操作。 数据库类型/版本【】；脱敏表结构【】；几行脱敏样例【】；目标问题与时间区间【】；允许读取的表和字段【】；预期输出列【】。 先解释连接键、过滤条件、空值和重复行将如何处理。返回单条 SELECT、参数说明、可能的重复放大风险和最多一条用于核对行数的小查询。SQL 中禁止写入/更新/删除/建表语句；如果主键、时间区间或单位不足以定义问题，先问清，不要把猜测塞进查询。
使用范围：AI适合起草查询与解释执行计划，不应直接操作生产库。禁止INSERT、UPDATE、DELETE、DDL和无条件全表扫描；不要接收真实凭证。
完成后的只读预览、影响行数与审批记录
先用 CTE 输出候选重复组、保留行、拟处理行与原因，共 14 组 19 行；业务确认其中 2 组为合法共享邮箱后排除。最终仅生成待审批 SQL 与影响 17 行的预览，没有自动执行。
为什么“影响行数符合预期，语义仍可能错”还不能交付
影响行数符合预期，语义仍可能错
- 原因
- 数量正确不代表选中了正确对象
- 怎么改
- 抽查每组业务键和关联表，先在事务中验证约束与回滚