向后兼容的数据库更改
内容提要
在进行数据库架构更改时，应将应用程序代码的更改与架构更改分开，以降低风险并避免部署冲突。推荐的“扩展、迁移和收缩”模式确保在任何步骤都能安全回滚，避免用户中断。具体步骤包括：扩展架构、更新应用代码以同时写入新旧架构、迁移数据、更新应用代码以仅读取新架构、收缩应用以只写入新架构，最后删除旧架构。此方法有效减少风险并提高效率。
延伸解读
为何要避免同时部署数据库与应用更改
文章指出，同时部署数据库架构和应用代码更改会带来多重风险：一是风险加倍，两个关键系统同时变更，出错概率增加；二是无法原子部署，若相互依赖，应用会短暂报错；三是迁移时间可能很长，从30秒到数小时甚至超过一天，阻塞应用部署；四是若数据库变更出错，会阻塞整个开发流水线；五是分离部署能强制遵循向后兼容的最佳实践。因此，应将两者解耦。
扩展、迁移和收缩模式的适用场景
该模式适用于任何涉及生产应用已在使用架构的变更，如重命名列或表、更改列数据类型、拆分或修改现有列或表的数据。如果只是添加不影响现有架构的新列或表，则无需此模式。模式的核心是确保每一步都可安全回滚，避免数据丢失和用户中断，从而降低风险，让团队能更快速、自信地推进变更。
模式各阶段的关键操作与注意事项
扩展阶段：添加新列或表，注意设为可空或提供默认值，避免写入错误；更新应用代码同时写入新旧架构。迁移阶段：运行脚本回填旧数据，若数据量大可用后台任务避免影响性能；然后更新应用代码只读新架构，部署前需确认数据准确。收缩阶段：确认无误后，更新应用只写新架构，最后删除旧列或表。删除前可考虑将列设为不可见或重命名以检测其他使用方。
实践中的回滚与性能监控
由于架构始终保持向后兼容，在迁移应用代码读取新架构后，仍可随时回滚应用代码，而不会造成数据丢失。在部署读取新架构的代码前，是最后一次确认数据迁移准确性的机会，部署后若出现严重问题可能影响用户，因此建议在此步骤测试性能。文章还建议使用性能监控工具（如Insights）确保一切按预期工作。
Q&A
为什么在数据库架构更改时要将应用程序代码的更改与架构更改分开？
将应用程序代码的更改与架构更改分开可以降低风险，避免同时部署导致的错误和用户体验不佳。
什么是“扩展、迁移和收缩”模式？
“扩展、迁移和收缩”模式是一种确保数据库架构更改安全回滚的步骤，包括扩展架构、迁移数据和收缩架构。
在进行数据库架构更改时，如何确保用户不受影响？
通过使用“扩展、迁移和收缩”模式，可以在每个步骤中安全回滚，确保用户在迁移过程中不受影响。
进行数据迁移时需要注意哪些事项？
在数据迁移时，需要运行迁移脚本，并考虑数据量大的情况下使用后台作业，以避免影响生产数据库性能。
如何处理数据库架构中列或表的删除？
在删除列或表之前，确保应用程序只写入新架构，并可以选择将旧列或表改名以避免数据丢失。
为什么同时部署数据库和应用程序的更改会增加风险？
同时部署会导致两个关键系统的更改相互依赖，增加出错的可能性，可能导致应用程序短暂错误。
