4. 变更影响分析：前向兼容性、后向兼容性、数据迁移影响、应用层影响

好，咱们进入第四章。前面几章聊了聊为什么要管 Schema 变更，以及怎么管。这一章，我想跟你聊聊一个更实际的问题——变更到底会影响什么？

说白了，你改了一个字段，可能不只是改了一个字段那么简单。它可能让旧代码跑不起来，也可能让新代码读不到数据，还可能让线上服务直接挂掉。我见过太多因为没做影响分析就上线的变更，最后搞得鸡飞狗跳。

所以，这一章我们聚焦四个维度：前向兼容性、后向兼容性、数据迁移影响、应用层影响。把这四个维度吃透了，你就能在变更前把风险摸个七七八八。

4.1 前向兼容性 vs 后向兼容性

这两个概念，很多人容易搞混。我简单解释一下：

• 后向兼容性（Backward Compatibility）：新代码能读旧数据。或者说，Schema 升级后，旧版本的应用还能正常工作。
• 前向兼容性（Forward Compatibility）：旧代码能读新数据。或者说，Schema 升级后，新版本的应用产生的数据，旧版本的应用也能处理。

嗯，这里要注意：大多数数据库变更只保证后向兼容，不保证前向兼容。你想想看，你给表加了一个 NOT NULL 字段，旧代码往里面插数据时没传这个字段，直接就报错了。这就是破坏了后向兼容。

4.1.1 常见兼容性场景

变更类型	后向兼容	前向兼容	说明
新增可空字段	✅ 是	✅ 是	最安全的变更，新旧代码都能处理
新增非空字段（有默认值）	✅ 是	❌ 否	旧代码插入时需注意默认值
新增非空字段（无默认值）	❌ 否	❌ 否	破坏性变更，必须避免
删除字段	❌ 否	❌ 否	旧代码可能还在读这个字段
修改字段类型（扩大范围）	✅ 是	❌ 否	如 VARCHAR(50) → VARCHAR(100)
修改字段类型（缩小范围）	❌ 否	❌ 否	可能导致数据截断或转换失败

4.2 数据迁移影响

数据迁移，是 Schema 变更里最容易被低估的一环。很多人觉得「不就是改个表结构嘛，ALTER TABLE 一下就好了」。但实际呢？

我曾经在一个千万级的大表上执行 ALTER TABLE ADD COLUMN，结果锁表锁了 20 分钟，线上服务直接超时报警。从那以后，我再也不敢小看数据迁移的影响了。

4.2.1 数据迁移的三大风险

• 锁表风险：MySQL 的某些 DDL 操作（如添加索引、修改字段类型）会锁表，导致读写阻塞。对于大表，这可能意味着分钟级的不可用。
• 数据一致性风险：迁移过程中，如果数据还在写入，新旧 Schema 之间的数据映射可能出错。比如你改了字段名，但迁移脚本没处理好，数据就丢了。
• 回滚风险：迁移一旦开始，回滚就不是简单的「撤销」了。你可能需要把数据从新结构再转回旧结构，这个过程本身就有风险。

4.2.2 数据迁移策略对比

策略	适用场景	优点	缺点
原地 ALTER	小表（< 100 万行）	简单、快速	锁表、不支持回滚
在线 DDL（pt-osc/gh-ost）	大表（> 100 万行）	不锁表、可暂停	需要额外资源、有延迟
双写迁移	核心表、零停机要求	零停机、可灰度	实现复杂、需要双倍存储
逻辑导出导入	跨版本升级、重构	彻底、可校验	耗时、需要停机窗口

4.3 应用层影响

数据库变了，应用层不可能没感觉。你想想看，你的 ORM 映射、SQL 查询、缓存逻辑，全都跟 Schema 绑在一起。改一个字段，可能牵一发而动全身。

4.3.1 应用层受影响的主要方面

• ORM 映射：如果你用 Hibernate、MyBatis、JPA 这类框架，字段名或类型的变更会导致映射失败。我见过一个案例，只是把字段名从 user_name 改成 username，结果 MyBatis 的 ResultMap 没更新，线上直接 500。
• SQL 查询：硬编码的 SQL 语句、存储过程、视图，都可能因为 Schema 变更而失效。特别是那些藏在代码深处的动态 SQL，排查起来很痛苦。
• 缓存层：如果缓存了数据库的字段结构（比如 Redis 里存了 JSON 序列化的对象），Schema 变更后，旧缓存可能反序列化失败。这时候需要做缓存预热或版本化处理。
• 消息队列：如果数据库变更通过 CDC（Change Data Capture）同步到消息队列，下游消费者可能因为字段变化而解析失败。

4.4 影响分析框架图

下面这张图，是我自己总结的影响分析框架。每次做变更前，我都会对着这张图过一遍，确保没有遗漏。

4.5 总结一下

这一章我们聊了变更影响分析的四个核心维度。说白了，就是回答四个问题：

1. 后向兼容：新 Schema 会不会让旧代码报错？
2. 前向兼容：旧 Schema 能不能处理新数据？
3. 数据迁移：迁移过程会不会锁表、丢数据、难回滚？
4. 应用层：ORM、SQL、缓存、消息队列，有没有跟着改？

这四个问题，每一个都值得你花时间认真过一遍。别嫌麻烦，线上出一次事故，比做十次影响分析都更耗时。