一次看似安全的 MySQL 升级，为何把外键指向了错误用户
一位工程师为结束旧版数据库的 AWS 延长支持费用，先升级一台“绿色”副本，确认服务正常后再切换。一个小时后，业务报出怪异问题：表 X 原来 ID 为 1 的记录，在新库里变成了 26；六张关联表中五张仍指向正确对象，只有一张把这些数字当成旧库 ID，悄悄连到了完全不同的记录。
作者：林岚｜OC 开发者生态编辑
一位工程师为结束旧版数据库的 AWS 延长支持费用，先升级一台“绿色”副本，确认服务正常后再切换。一个小时后，业务报出怪异问题：表 X 原来 ID 为 1 的记录，在新库里变成了 26；六张关联表中五张仍指向正确对象，只有一张把这些数字当成旧库 ID，悄悄连到了完全不同的记录。
一句话结论：升级只是让问题暴露，真正的根因是更早的一次主键迁移：AUTO_INCREMENT 在源库和副本上按不同顺序编号，再被 MIXED binlog 的两种复制方式拼成了语义不一致的数据。
事故起点是一条看上去普通的迁移：给既有表 X 增加自增主键。MySQL 文档明确提醒，在被复制的表上通过 ALTER TABLE 添加 AUTO_INCREMENT 列，源库和副本不一定以相同顺序处理行，因此同一条业务记录可能拿到不同数字。复制没有停止，数据行也都在，可“ID 代表谁”已经分叉。
随后，迁移脚本更新六张关联表，用旧业务键连接表 X，再把新 id 写入外键。在源库看来，六次更新都正确。问题出在实例使用 binlog_format=MIXED：默认按语句记录，但遇到 MySQL 判断不安全的情况会切换成按行记录。
五张表的更新以 STATEMENT 方式复制。副本重新执行 JOIN，于是读取的是副本本地的 X.id，虽然数字和源库不同，关系仍然正确。剩下一张表因为自身带有自增列等差异，被 MySQL 切到 ROW 方式；副本不再执行 JOIN，而是直接接收源库算出的 x_id 数字。数字被忠实复制，语义却已错位。
这正是事故难发现的地方。行数相等、复制延迟归零、抽样接口可用，甚至绝大多数关联表都正确。传统升级检查关注“数据有没有丢”，而这里需要检查“同一个标识在两边是否仍代表同一个实体”。只比主键集合，仍然看不出错链。
更稳妥的做法，是在迁移前避免让副本各自推导不确定的代理键；若必须添加，先固定确定性映射并验证源副本的一致性。切换前要做基于业务键的 JOIN 校验，统计孤儿外键和错配关系，并审计迁移期间每条语句实际采用的 binlog 格式。备份和可回滚切换当然必要，但它们不能替代语义校验。
关键事实
- 来源：事故作者复盘、MySQL 复制机制说明
- 根因：源库与副本为既有行分配了不同的自增 ID
- 放大条件：MIXED binlog 在不同更新上分别采用 STATEMENT 与 ROW
- 表现：六张关联表中五张关系正确，一张复制了源库数字却指向副本中的错误对象
OC 判断
“副本升级成功”只能证明数据库能运行，不能证明业务关系仍然成立。代理主键看似只是整数，一旦跨实例独立生成，就必须把它当成带语义的数据。问题不在某一个 MySQL 开关，而在迁移设计默认了编号稳定、检查流程又只验证了可用性。
为什么重要
- 对开发者：增加自增主键不是纯结构变更，可能改变跨副本的实体映射。
- 对运维团队：切换演练必须包含业务键与外键语义校验。
- 对企业：静默错链往往比停机更危险，因为错误可能持续写入并污染后续数据。
评论
围绕这篇文章补充信息、提出问题或分享观察。