大表加字段怎么上线提示词：数据库变更安全方案（在线 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 条评论
还没有评论，来抢沙发～