数据库迁移怎么做才不出事
方案写得越顺，越要有人认真否它一次。数据出事通常不是脚本写错，而是没人想过中途失败怎么办。
怎么做
先圈出这次迁移会碰到谁
把表结构变更、依赖关系和流量规模给「估算一次改动的风险面」。列受影响的读写方、定时任务、报表和下游，按影响人数和恢复难度排前三，并给回退指标。这份清单是下一步审方案的输入，不是上线时才看的附件。
找人把方案否一遍
把方案连同数据量、停机窗口、回滚办法和依赖方配合情况给「否决这个迁移方案」。它会列让迁移失败的具体条件、被当成「到时候再说」的问题，以及更小的替代路径，比如先迁一部分、先双写、先只迁读。最后才看哪两条补上就能过。
写迁移、回滚、校验三件套
把表结构和变更目标给「写可回滚的数据迁移脚本」。要求分批、可重入、每批有上限，避免长事务锁表；标出不可逆的操作和回滚后的核对方式；校验 SQL 在回填后、切换前、回滚前各跑一次并给阈值。先让它指出最可能丢数据的一步。
索引跟着查询走，不跟着字段走
把表结构、数据量和慢查询给「评审数据库索引设计」。逐个索引写出它对应哪条查询的 WHERE 或 ORDER BY，标出冗余、永远用不上和会失效的写法，估算写入与存储影响，最后给保留、删除、新增三栏结论。新索引在迁移完成后建，避开写放大。
用真实查询验证，而不是看行数
迁移后在影子库或只读副本上，把 Top 查询给「SQL 性能优化」。带上表名、行数、耗时和执行计划，让它指出瓶颈、给出改写和需要补的索引，并说明写入变慢的副作用。不要在生产上直接试，也不要只看「数据都导过去了」。
用到的提示词
常见问题
数据库迁移一定要停机吗
不一定，要看变更类型。加可空字段、并发建索引通常能在线做；改字段类型、拆表、改主键往往要双写或分批回填，停机只发生在最后切换的一小段。先把变更归类，再决定窗口。
迁移脚本要不要写回滚
要，而且要和迁移脚本一起评审。删列、覆盖数据这类操作本质上不可逆，回滚脚本只能恢复结构，所以第 3 步要求先标出不可逆的那一步，并准备备份或双写。
几百万行的表怎么迁
分批，每批有上限并记录进度，保证可重入；先在少量数据或影子库跑通，再按批次推进。不要用一条大事务改完，锁表时间和失败代价都不可控。