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 條評論
還沒有評論，來搶沙發～