1. Schema Drift 概述：同步中的“表结构地震”

大家好，我是老赵。做数据同步这些年，踩过最大的坑，就是 Schema Drift。

说白了，Schema Drift 就是源端表结构偷偷变了，而你的同步任务还蒙在鼓里。我见过太多案例——凌晨三点告警响成一片，一看日志：字段没了、类型改了、新增列导致写入失败。嗯，那感觉，真酸爽。

1.1 什么是 Schema Drift

Schema Drift，中文叫“表结构漂移”。指的是在数据同步过程中，源数据库的表结构发生了变更，而目标端没有同步更新，导致两边结构不一致。

举个例子：

• 源表 orders 原本有 id、amount、create_time 三列
• 业务方在源表新增了 discount 列
• 同步任务还在按三列写入目标表
• 结果：新数据写不进去，或者写进去但丢了字段

这就是典型的 Schema Drift。你想想看，一个线上同步链路，每天跑几千万条数据，突然因为一个字段变更全崩了——这种事，我经历过不止一次。

1.2 为什么会产生 Schema Drift

原因其实不复杂，但很现实。我归纳了最常见的几种场景：

我个人习惯把 Schema Drift 分为两类：主动变更和被动变更。主动变更是业务方有计划地改表，被动变更是你根本不知道谁动了表结构。后者才是真正的噩梦。

1.3 Schema Drift 对数据同步的影响

影响有多大？我直接说结论：轻则丢数据，重则整个同步链路瘫痪。

具体来说，有这几个层面：

1. 写入失败：目标表没有新增列，源端多写了字段，INSERT 直接报错
2. 数据截断：源端字段长度从 VARCHAR(100) 改成 VARCHAR(500)，目标端还是 100，长文本被截断
3. 类型转换异常：源端 INT 改成 BIGINT，目标端写入时溢出
4. 数据丢失：源端删除了某列，同步任务还在读该列，读不到就写 NULL，业务逻辑全乱
5. 同步延迟暴增：遇到结构变更，同步任务反复重试，积压大量数据

你想想看，一个实时同步链路，延迟从秒级变成小时级，业务方会怎么想？

1.4 Schema Drift 的典型场景图解

下面这张图，是我在项目中经常用来跟团队讲清楚 Schema Drift 的流程。你看一遍就明白了。

你看，源端改了表结构，同步任务还在按老结构跑，结果就是写入失败或者数据异常。这个链条一旦断裂，恢复起来非常麻烦。

1.5 为什么我们要重视 Schema Drift

说实话，很多团队一开始不重视这个问题。觉得“改个表而已，手动改一下同步配置不就行了？”

但现实是：

• 一个中大型数据平台，同步的表可能有几百上千张
• 业务迭代频繁，每周都有表结构变更
• 手动维护根本跟不上节奏
• 一旦出问题，恢复时间往往以小时计

我记得有一次，某电商大促期间，订单表新增了一个 promotion_id 字段。同步任务没感知到，结果所有新订单的促销信息都没同步过去。业务方第二天发现数据对不上，追查了整整一个上午。那之后，我们团队把 Schema Drift 检测列入了同步系统的核心能力。