数据库迁移
数据库迁移（Migration）是一种版本控制数据库结构变更的机制，允许开发团队以可追溯、可回滚的方式管理数据库表结构的演化，是生产级软件工程的重要实践
核心事实
时间轴 (近 90 天)
区分迁移失败类型：结构错误的变更应回滚，结构正常但遇到网络抖动的变更应重试。
应给每个迁移设置语句超时，没有超时会导致抢锁的迁移阻塞表上所有查询，拖垮整个应用。
回填应按批处理，避免在一个事务里锁住大量行（如五万行）。
重命名列实际上是两个操作伪装成一个，朴素写法会在回滚时丢数据；删列没有诚实的 down，因为数据已经没了。
部署期间存在一个窗口，旧代码和新代码同时存在，数据库可能在三十秒到两分钟内同时服务两个版本。
迁移的核心契约是成对出现：up 定义如何把结构推进到新版本，down 定义如何回到上一个版本。
一套可靠的迁移规范通常包含：命名带时间戳保证顺序、禁止在迁移里调用应用模型代码、对生产大表操作时显式声明锁策略、在预发环境跑完整的 up-down-up。
避免大多数凌晨事故的单条规则：加法迁移在部署前跑，破坏性迁移在部署后跑。
回滚必须在当前存活的结构上生效，完全不运行任何 down 迁移。如果做不到，就是迁移顺序错了。
对于大表上的长回填，如果因连接断开、锁超时或副本落后而中途失败，应使迁移可安全重跑，使用幂等回填（复制目标仍为空的行）和带退避与抖动的重试，而非回滚。
还有 4 条时间轴事件
全部知识事实 (14)
迁移（Migration）是一种以版本化 SQL 脚本管理数据库结构变更的工程实践，可追溯、可回滚、可在不同环境一致地重放
75%待验证区分迁移失败类型：结构错误的变更应回滚，结构正常但遇到网络抖动的变更应重试。
50%待验证回填应按批处理，避免在一个事务里锁住大量行（如五万行）。
50%待验证重命名列实际上是两个操作伪装成一个，朴素写法会在回滚时丢数据；删列没有诚实的 down，因为数据已经没了。
50%待验证部署期间存在一个窗口，旧代码和新代码同时存在，数据库可能在三十秒到两分钟内同时服务两个版本。
50%待验证迁移的核心契约是成对出现：up 定义如何把结构推进到新版本，down 定义如何回到上一个版本。
50%待验证一套可靠的迁移规范通常包含：命名带时间戳保证顺序、禁止在迁移里调用应用模型代码、对生产大表操作时显式声明锁策略、在预发环境跑完整的 up-down-up。
50%待验证避免大多数凌晨事故的单条规则：加法迁移在部署前跑，破坏性迁移在部署后跑。
50%待验证回滚必须在当前存活的结构上生效，完全不运行任何 down 迁移。如果做不到，就是迁移顺序错了。
50%待验证对于大表上的长回填，如果因连接断开、锁超时或副本落后而中途失败，应使迁移可安全重跑，使用幂等回填（复制目标仍为空的行）和带退避与抖动的重试，而非回滚。
50%待验证应给每个迁移设置语句超时，没有超时会导致抢锁的迁移阻塞表上所有查询，拖垮整个应用。
50%待验证可回滚的前提是操作幂等或有事务保障，数据库变更应优先使用迁移脚本而非直接SQL，文件变更应纳入版本控制
50%待验证每个迁移脚本通常包含一个 up（正向变更）和一个 down（回滚）操作，并以时间戳或序号排序
50%待验证生产环境中的schema变更是高风险操作，字段类型变更可能导致存量数据无法解析，删除列会造成数据永久丢失
50%