源端 DDL 为什么危险
源端 DDL 是 CDC 链路高频的事故源：加列通常影响小，删列、改类型、改主键会让下游解析或写入直接失败；RENAME 与 TRUNCATE 在 binlog 里表现为 QUERY 事件而不是行事件，所以只依赖行事件的下游根本收不到「表已被清空」这个信息。落地要有「先让下游兼容、再执行变更」的发布流程，工具侧只能缓解，替代不了流程。
基本信息
| 低风险变更 | 新增可空列，下游按列名取值时通常无感 |
|---|---|
| 高风险变更 | 删列、改类型、改主键，可能导致解析或写入失败 |
| 特殊事件 | TRUNCATE 与 RENAME 在 binlog 中是 QUERY 事件，无逐行删除 |
| 应对原则 | 下游先兼容再执行 DDL，避开结算与大促窗口 |
典型使用场景
- 新增字段：先确认下游按列名还是按列位置解析
- 字段下线：先双写观察，再清理旧列
- 表重命名：同步调整主题映射与下游消费逻辑
- 清表操作：TRUNCATE 后手工同步目标端清空，避免行数长期不一致
- 发布流程：把 DDL 纳入变更审批，提前通知数据下游
变更前后的核对动作
变更前后的核对动作
-- 变更前：确认当前结构与目标基线
SHOW CREATE TABLE app.orders\G
SELECT COUNT(*) FROM dw.orders;
-- 变更后：核对目标端是否出现解析或写入错误、行数是否出现偏差
-- 常规做法：先加可空列 → 双写观察一段时间 → 再清理旧列变更类型与风险
| 变更类型 | binlog 表现 | 下游风险 |
|---|---|---|
| ADD COLUMN | QUERY 事件，后续行事件带新列 | 按固定列数组解析的下游报错或丢列 |
| DROP 或 RENAME COLUMN | QUERY 事件 | 按旧结构解析然后错位 |
| 改数据类型 | QUERY 事件 | 类型不兼容导致写入失败 |
| TRUNCATE | QUERY 事件，无逐行删除 | 目标端未同步清空，行数长期对不上 |
| RENAME TABLE | QUERY 事件 | 主题与表的映射失效 |
常规做法是先加可空列、双写观察一段时间、再清理旧列；大促或结算窗口内避免执行 DDL，一次解析失败可能要回滚整条链路。
不同 CDC 工具对 DDL 的支持程度差别很大：有的记录结构历史并自动适配，有的只保证不崩；接入前先用工具文档确认支持边界，不要靠试。