蓝绿与数据库兼容是什么
蓝绿部署切换期间，新旧两套应用同时连接同一个数据库，因此数据库结构必须同时兼容两个版本的代码。兼容性约束决定发布节奏：加列、加索引这类向后兼容的变更可以在切换窗口内做，删列、改名、改类型等破坏性变更必须等旧版本完全退役。这一思路即「扩容-收缩」（Expand-Contract）：先扩展结构，再迁移流量，最后收缩清理。
基本信息
| 约束窗口 | 新旧两个版本同时在线的时间段 |
|---|---|
| 允许的变更 | 兼容扩展：加列、加索引、加表、双写 |
| 延迟执行 | 删列、改名、改类型等破坏性操作 |
| 数据对账 | 双写与回填期间核对新旧路径的一致性 |
| 回退前提 | 旧结构在回退后仍可用，旧代码不被新结构击穿 |
变更类型与执行时机
| 变更 | 窗口内可否 | 说明 |
|---|---|---|
| 加列 | 可以 | 必须可空或带默认值，旧代码忽略新列 |
| 加索引 | 可以 | 大表用在线方式建立，避免长时间锁表 |
| 双写 | 可以 | 新代码同时写新旧字段，便于回退 |
| 删列改名 | 退役后 | 旧代码仍引用旧结构时会直接报错 |
| 改类型 | 谨慎 | 通常先加新列、回填、再切换读取 |
典型迁移顺序
典型迁移顺序
# 1 加新列，旧代码忽略新列
# 2 部署新代码并双写
# 3 回填历史数据
# 4 验证新旧路径数据一致
# 5 旧版本完全退役后删除旧列
# 每一步都可独立回退典型使用场景
- 蓝绿或滚动发布前：逐条审计数据库迁移脚本的向前与向后兼容性
- 回退演练：确认旧代码在新结构上仍能正常读写，回退路径通畅
- 大表结构变更：选择在线更改或分批回填，避免锁表拖慢线上写入
- 多服务共享库：一个服务的迁移可能影响其他服务的旧版本代码，需全量排查
- 清理阶段：确认没有任何版本引用旧列之后，再执行收缩删除
数据库是发布兼容性的主要约束点：迁移计划应按「两版本同时在线」的窗口来推导，而不是按单版本假设。
回退时结构变更不会自动回退：删除旧结构后旧版本无法恢复运行，破坏性变更务必等到确定不再回退再执行。