1. 全量迁移的痛点：为什么不能一直用全量？
说实话，我刚入行那会儿也觉得全量迁移挺省心的。每天凌晨跑个脚本，把整个数据库导一遍，完事。但后来数据量从几百 GB 涨到几十 TB，问题就全冒出来了。
你想想看，全量迁移就像搬家——东西少的时候一趟搞定，东西多了就得来回跑。但数据搬家可不像搬家具那么简单，它是有时间窗口的。
1.1 数据量大：跑不完的迁移任务
我遇到过最夸张的一次，客户说「全量迁移 8 小时能跑完吧？」结果一算，单表 5 亿行，光扫描就要 6 小时，再加上网络传输、目标端写入……嗯，最后跑了 14 小时。
为什么会这样？因为全量迁移的复杂度是 O(n) 的——数据量翻倍，时间就翻倍。这不是优化能解决的。
| 数据规模 | 全量迁移耗时（估算） | 常见瓶颈 |
|---|---|---|
| 100 GB | 30 分钟 - 1 小时 | 网络带宽 |
| 1 TB | 3 - 6 小时 | 磁盘 IO + 网络 |
| 10 TB | 30 - 60 小时 | CPU + 内存 + 网络 |
| 100 TB | 12 天以上 | 全部资源都吃紧 |
核心结论：全量迁移的时间成本与数据量成正比。当数据量超过 1 TB，单次全量迁移基本不可能在业务低峰期（通常 4-6 小时）内完成。
1.2 窗口时间短：业务不等人
我习惯把迁移窗口比作「红灯时间」——业务停得越久，损失越大。金融、电商、游戏这些行业，凌晨 2 点到 6 点就是黄金窗口，过了 6 点用户开始活跃，你还在跑迁移？等着被投诉吧。
全量迁移有个致命问题：它要求源端数据在迁移期间保持静止。但现实是，业务系统 7×24 小时都在写入。你刚导完一批数据，源端又变了。这就导致两个后果：
- 数据不一致：迁移完成时，源和目标的数据已经对不上了
- 需要停机：必须暂停写入，等迁移完再恢复——停机时间 = 迁移时间
我曾经帮一个电商平台做迁移，他们要求停机不超过 2 小时。全量方案一算，光导出就要 3 小时。最后只能拆表、分批、并行……折腾一圈，还是超了 40 分钟。老板脸都绿了。
避坑提醒：不要相信「全量迁移 + 手动补数据」的方案。我曾经这么干过，结果补数据时又产生新数据，陷入死循环。最后不得不回滚，白白浪费一个周末。
1.3 资源消耗高：把系统跑崩了
全量迁移不只是「慢」，它还会把源端系统拖垮。我见过最惨的一次，DBA 跑全量导出，直接把生产库的 CPU 打满，业务查询全部超时，报警电话打爆了。
资源消耗主要体现在三个方面：
- CPU：全量扫描需要大量计算，尤其是带复杂查询的迁移
- 磁盘 IO：顺序读 + 随机写，磁盘队列深度飙升
- 网络带宽：几十 TB 的数据在网络上跑，其他业务基本别想用了
我个人的经验是：全量迁移时，源端系统的性能会下降 30%-50%。如果业务本身负载就高，那基本等于「自杀式迁移」。
一个小技巧：如果你不得不做全量迁移，建议用 SELECT /*+ PARALLEL */ 控制并行度，别把资源吃满。同时监控源端的 CPU 和 IO 等待，超过 70% 就降速。
1.4 全量迁移的瓶颈全景图
下面这张图是我自己总结的，把全量迁移的三大瓶颈串在了一起。你看一眼就明白了。
1.5 什么时候还能用全量？
说了这么多全量的坏话，但我也不是完全否定它。全量迁移在以下场景仍然适用：
- 数据量小于 100 GB：一次迁移能在 1 小时内完成，风险可控
- 允许长时间停机：比如离线系统、测试环境，停机 8 小时也没关系
- 一次性迁移：迁移完成后源端不再使用，不需要持续同步
- 作为增量迁移的「基线」：先全量同步一次，后续用增量持续追