大表加字段怎麼上線提示詞：數據庫變更安全方案（在線 DDL、鎖表風險、分批迴填、回滾）
要給幾千萬行的線上大表加字段、加索引、改字段類型，擔心鎖表把業務卡死時用：讓 AI 評估這次變更的鎖和耗時風險，給出「先兼容、再遷移、後清理」的分步方案、在線變更工具的用法、分批迴填腳本和每一步的回滾辦法。
通用大模型 對話模型通用
你是一名負責線上數據庫變更的 DBA。請為下面的表結構變更制定安全的上線方案。 - 數據庫與版本：[數據庫與版本]（例：MySQL 8.0、PostgreSQL 15） - 表名、行數、表大小：[表名、行數、表大小]（例：orders，8000 萬行，60GB） - 要做的變更：[要做的變更]（例：新增 NOT NULL 字段並回填歷史數據、把 INT 改為 BIGINT） - 當前表結構與索引： [粘貼建表語句] - 業務寫入情況：[業務寫入情況]（例：每秒 300 次寫入，凌晨 3 點到 5 點低峰） - 部署方式：[如主從複製、雲數據庫、有沒有隻讀從庫] - 應用發佈方式：[如滾動發佈，新舊版本會同時運行一段時間] 請輸出： 1. 風險評估：這項變更在當前版本下是否會鎖表、鎖多久、會不會重建整張表、對主從延遲的影響、需要多少額外磁盤空間。說明判斷依據，拿不準的寫「需在同版本測試環境用同量級數據驗證」。 2. 分步方案（擴展 → 遷移 → 收縮）： - 第一步只做向後兼容的變更（如先加允許為空的字段），舊版本代碼不受影響； - 應用代碼同時兼容新舊結構（讀寫都能處理新字段為空的情況），再發布； - 分批迴填歷史數據：每批行數、批間暫停、按主鍵範圍推進、可中斷續跑、觀察主從延遲； - 回填完成並校驗後，再加約束或刪除舊字段。 3. 執行方式：數據庫原生的在線變更能力是否適用；如果不適用，使用在線變更工具的方式與關鍵參數（說明工具的原理和注意事項，比如觸發器或複製日誌帶來的額外負載）。 4. 回填腳本：給出腳本，要求冪等、記錄進度、遇到錯誤停止而不是跳過。 5. 執行清單：執行前檢查（備份、磁盤空間、長事務、從庫延遲）、執行中監控項、中止條件。 6. 回滾方案：每一步分別怎麼回滾，哪一步之後回滾變得困難。 不要建議在業務高峰期直接執行會鎖表的變更。
高亮處換成你自己的內容：[數據庫與版本]、[表名、行數、表大小]、[要做的變更]、[粘貼建表語句]、[業務寫入情況]、[如主從複製、雲數據庫、有沒有隻讀從庫]、[如滾動發佈，新舊版本會同時運行一段時間]
ChatGPT Plus 充值
已被複製 0 次
使用說明
怎麼填變量：[數據庫與版本] 必須精確到小版本，不同版本對在線變更的支持差別很大：有些操作在新版本中幾乎瞬間完成，在舊版本中會重建整張表。[應用發佈方式] 決定了是否需要「代碼同時兼容新舊結構」這一步，滾動發佈期間新舊代碼會同時訪問數據庫。
常見坑：
- 一步到位地加一個 NOT NULL 帶預設值的字段，並在同一次發佈裏讓代碼依賴它。一旦變更耗時超出預期或需要回滾，代碼和表結構就對不上了。
- 一條 UPDATE 回填全表，產生一個巨大的事務，主從延遲飆升，甚至撐爆日誌。要按主鍵分批，小批量、可中斷。
- 變更前沒檢查長事務。一個沒提交的長事務會讓變更一直等鎖，而排在後面的正常查詢也會被阻塞，看起來就像「數據庫掛了」。
追問技巧：執行前追問「列出執行過程中出現哪些現象時必須立即中止，以及中止的命令」，打印出來放在手邊。
示例輸出
示例，僅供參考（MySQL 8.0，orders 表新增 channel 字段，節選）
| 步驟 | 操作 | 回滾 |
|---|---|---|
| 1 | ALTER TABLE orders ADD COLUMN channel VARCHAR(16) NULL（需驗證本版本能否用即時算法完成） | 刪除該字段 |
| 2 | 發佈代碼：新訂單寫入 channel，讀取時為空按「unknown」處理 | 回滾代碼 |
| 3 | 分批迴填歷史數據 | 停止腳本，已回填的數據不影響舊代碼 |
| 4 | 校驗無空值後，再改為 NOT NULL | 改回允許為空 |
sql
-- 回填：每批 5000 行，按主鍵推進，可重複執行
UPDATE orders SET channel = 'app'
WHERE id > @last_id AND id <= @last_id + 5000 AND channel IS NULL;同款作品
用這條提示詞做出來的作品；原作者會因此獲得積分
還沒有同款，來做第一個。
0 條評論
還沒有評論，來搶沙發～