📚 课程目录第1章数据迁移概述

第一章数据迁移概述：定义、重要性与常见场景

大家好，我是这次课程的主讲。开场咱们先聊点实际的——数据迁移这件事，说白了就是把数据从一个地方搬到另一个地方。听起来简单吧？我早年做项目时也这么想，直到有一次凌晨三点还在回滚数据库，才明白这四个字背后有多少坑。

不是所有搬数据的行为都叫迁移。你手动导个 CSV 文件发邮件，那叫搬运。你写脚本把 MySQL 表同步到 Elasticsearch，那叫同步。真正的数据迁移，是一个有始有终、可验证、可回滚的工程过程。它要解决的不只是「把数据拷过去」，而是「如何让业务不停、数据不丢、结果可对账」。

从技术角度定义，数据迁移是指将数据从源系统（Source）完整、准确地传输到目标系统（Target），并确保目标系统能正常承载业务访问的工程活动。它通常包含三个阶段：评估与规划、执行与校验、切换与收尾。

    核心三要素：

    完整性（数据不丢）

    一致性（数据不脏）

    可用性（业务不停）

嗯，这里要注意一个误区。很多人觉得数据迁移就是「同步工具 + 脚本」，做完就完了。我个人习惯把迁移拆成两阶段：全量迁移和增量追平。全量搬过去只是开始，增量追平到秒级，才算真正具备切换条件。

你想想看，现在哪个系统不是迭代了好几年？数据库从单机到集群，存储从本地盘到云盘，业务从单体到微服务。每一次技术架构的演进，背后几乎都要走一次数据迁移。

我记得有个电商客户，双十一前把核心订单库从 MySQL 迁到分布式数据库。方案评估很充分，但忽略了数据校验的时间窗口。切过去后发现两张表差了 3000 条记录，业务已经跑起来了，回滚损失超过两小时交易数据。那一次之后，我给自己定了个规矩：没有回滚方案的迁移，等于赌博。

我的经验：数据迁移不只是技术活，更是项目管理。你至少要留出 20% 的工期给「验证和回滚演练」。别急着切，切之前先跑一遍完整的回滚流程，证明它能工作。

数据迁移的重要性可以归纳为三点：

做过几年迁移的朋友应该能感受到，场景十个人有九个样，但抽离出来无非这几类模式：

说到场景，我想起一个经典问题：什么时候需要做增量迁移，什么时候只用全量就够了？

全量迁移适合离线、允许停机、数据量不大的情况。比如凌晨三点你停服两个小时，一次性把几百万条记录倒过去。但凡业务要求灰度切换、分钟级回滚、或者数据量上亿，就得走「全量 + 增量」的模式。全量把存量数据搬完，增量同步把切换期间的变更补上，最后在秒级内完成割接。

注意：我曾经遇到一个项目，全量迁移跑了 12 个小时，增量同步工具只支持单线程写入。源库每小时产生 50 万新记录，增量根本追不上。后来被迫改成批量写入加并行管道。做方案时一定要算好流量差值，源库写入速度 / 增量同步速度不能大于 1。

下面这张图是我画的一个概念骨架。它会贯穿咱们整个课程，后面每讲都会往这个骨架里填细节。

从图里你能看到，我把数据迁移拆成四个关键阶段——评估与规划、执行与校验、切换与收尾、回滚与复盘。大部分教程只讲中间两步，但我认为规划和回滚才是决定成败的 60%。

举个例子，你花三天写迁移脚本，但没做源数据字典的字段级映射。上线前测试发现目标库表结构少了一个字段 —— 这种坑我栽过。

后面章节我会手把手带你拆每一步怎么做，包括怎么用 SDK 封装迁移能力、怎么设计回滚策略、怎么把校验逻辑固化到代码里。嗯，今天先到这里，内容不少，建议你自己动手画一遍这个框架，把每个阶段下你可能遇到的问题列出来。

第一章 数据迁移概述：定义、重要性与常见场景