从MongoDB迁移至MySQL时的ID处理方案咨询（需保留ObjectID）

先逐个拆解你提到的三个方案：

方案一：直接用ObjectID做主键 #

优点是迁移成本最低，完全不用改业务逻辑，但缺点很突出：

• 如果把ObjectID存成varchar(24)字符串做主键，InnoDB的聚簇索引会因字符串的随机性产生大量碎片，插入和查询性能随数据量增长会明显下降。
• 就算存成binary(12)（ObjectID原生是12字节二进制），虽然比字符串省空间，但依然是随机值，插入时无法像自增ID那样连续写入，还是会引发页分裂，长期性能不如自增主键。

方案二：单独建关联表映射新旧ID #

这个方案会额外增加业务复杂度：

• 每次查询都要先判断传入的是ObjectID还是新UUID，额外的判断逻辑容易出错。
• 查询旧ID时需要多一次关联查询，增加数据库IO开销，同时维护关联表也多了一层成本，比如数据同步、异常处理。

方案三：新增ObjectID列并建索引 #

你担心新行用不到这个列，但其实这是三者里最平衡的方案：

• 主键用MySQL原生的自增bigint，保证最优的插入和查询性能，自增ID连续写入，InnoDB聚簇索引不会产生碎片问题。
• 新增的列设为binary(12)或者varchar(24)，允许为NULL，仅在迁移历史数据时填充ObjectID，新行该字段留空即可。给这个列建普通索引，因为只有历史数据有值，索引体积不会太大，查询旧ID时能快速定位。
• 业务逻辑无需额外判断，查旧ID用该列，查新ID用主键，简单直接。

更优补充方案 #

可以对方案三做一点优化：把ObjectID列设为UNIQUE索引，既能避免重复的ObjectID（迁移时做一层校验），又能保证查询性能，唯一索引的查询效率和普通索引差别不大，但能强化数据唯一性。

另外，如果旧QR码的访问量极低，仅偶尔需要处理历史数据，也可以考虑把历史数据单独存到归档表，主表只用自增ID，需要查旧ID时再去归档表查询——但这个仅适合历史访问量极低的场景，否则还是方案三更实用。

总结下来，方案三是最优选择，平衡了性能、业务复杂度和维护成本，完全满足你保留ObjectID访问的需求。

内容的提问来源于stack exchange，提问作者afresquet