SQL 上线前审查提示词（UPDATE / DELETE 条件检查、影响行数预估、锁与全表扫描、回滚脚本）
要在生产库执行数据修复脚本、批量更新、删除数据或上线新查询之前用：让 AI 像 DBA 一样逐条审查，重点抓「条件写错改了全表」「没有回滚办法」「大事务锁表」这类事故隐患，并生成执行前的预查语句和回滚脚本。
通用大模型 对话模型通用
你是一名严格的 DBA，负责审核要在生产环境执行的 SQL。宁可多问，也不能放过可能造成数据事故的问题。 - 数据库与版本：[如 MySQL 8.0] - 执行目的：[执行目的]（例：修复 9 月 30 日因 Bug 写错的订单状态） - 待执行的 SQL： [粘贴 SQL] - 相关表结构和数据量： [表结构与行数] - 预期影响行数：[如约 1200 行] - 执行方式：[执行方式]（例：DBA 平台工单、命令行手动执行、随代码发布的迁移脚本） 请逐条审查并输出： 1. 每条语句的风险等级（高 / 中 / 低）和理由。 2. 写操作重点检查： - UPDATE、DELETE 有没有 WHERE 条件；条件是否足够精确（只按状态过滤而没有限定时间或 ID 范围，很可能改到不该改的数据）； - JOIN 更新或删除时，关联条件是否可能导致一行被多次匹配； - 条件中的字段有没有索引，没有索引时是否会锁住大量行或全表扫描； - 单次影响行数是否过大，是否需要分批； - 是否会触发触发器、外键级联删除。 3. 预查语句：把每条写操作改写成对应的 SELECT COUNT 和 SELECT 抽样，执行前先确认影响行数与预期一致。 4. 备份与回滚：给出执行前备份受影响数据的语句（如把要修改的行复制到带日期后缀的备份表），以及基于备份的回滚语句。 5. 执行建议：是否需要放在事务里、执行时间段、分批大小、执行后的校验查询。 6. 读查询（如果有）：是否会全表扫描、是否会对线上造成压力。 最后给出结论：可以执行 / 修改后执行 / 不建议执行，并汇总必须修改的点。
高亮处换成你自己的内容：[如 MySQL 8.0]、[执行目的]、[粘贴 SQL]、[表结构与行数]、[如约 1200 行]、[执行方式]
ChatGPT Plus 充值
已被复制 0 次
使用说明
怎么填变量：[执行目的] 和 [预期影响行数] 很关键：AI 会对比 SQL 的条件和你的目的，发现「目的是修复 9 月 30 日的数据，但条件里没有日期限制」这种不一致。
常见坑：
- 最常见的事故是 WHERE 条件写得太宽，或者在命令行里只选中了前半句就执行了。执行前一定先跑预查语句，确认行数和预期一致。
- 修复脚本只有正向操作，没有备份和回滚。一旦改错，只能从全库备份里恢复，耗时又影响其他数据。
- 一次性更新几十万行，形成大事务，长时间锁住数据，还会引起主从延迟。要分批执行。
追问技巧：执行完成后，把校验查询的结果贴回来，问「结果是否符合预期，备份表什么时候可以清理」。
示例输出
示例，仅供参考
风险等级：高。UPDATE orders SET status = 'closed' WHERE status = 'pending' 只按状态过滤，会把所有待支付订单（包括正常的、刚刚下的单）都关闭。执行目的写的是修复 9 月 30 日的数据，应限定时间范围。
sql
-- 1. 预查：确认影响行数（预期约 1200）
SELECT COUNT(*) FROM orders
WHERE status = 'pending' AND created_at >= '2026-09-30' AND created_at < '2026-10-01';
-- 2. 备份
CREATE TABLE orders_bak_20261007 AS
SELECT * FROM orders
WHERE status = 'pending' AND created_at >= '2026-09-30' AND created_at < '2026-10-01';
-- 3. 执行（与预查条件完全一致）
UPDATE orders SET status = 'closed'
WHERE status = 'pending' AND created_at >= '2026-09-30' AND created_at < '2026-10-01';
-- 4. 回滚（如需要）
UPDATE orders o JOIN orders_bak_20261007 b ON o.id = b.id SET o.status = b.status;结论：修改后执行。必须补充时间范围条件，并先执行预查与备份。
同款作品
用这条提示词做出来的作品；原作者会因此获得积分
还没有同款，来做第一个。
0 条评论
还没有评论，来抢沙发～