MongoDB中用_id存储自定义用户ID是否可行？存在哪些风险？

你的想法是合理的，这么做确实能减少数据冗余和维护复杂度：

• MongoDB的_id字段本身就是文档的主键，天生具备唯一性和不可变性，用它来存储用户ID完全符合MongoDB的设计初衷，没必要额外维护一个重复的自定义id字段。
• 去掉自定义id后，数据结构更简洁，后续维护时不用再考虑两个ID字段的同步问题，能降低出错概率。
• _id字段默认自带唯一索引，查询效率有保障，用数值型ID替代原来的ObjectID，在查询性能上也不会有明显损耗。

不过这个改动也存在不少需要注意的风险，得提前做好应对：

• 数据迁移的一致性问题：现有文档的_id是ObjectID类型，要替换成数值型的用户ID，需要批量更新整个集合。如果操作过程中出现中断、部分文档更新失败，很容易造成数据不一致。如果系统处于运行状态，还要考虑读写冲突，可能需要暂停服务或者采用双写（同时写旧ID和新ID）的过渡方案。
• 关联集合的引用断裂：如果其他集合（比如订单、评论）里有引用用户自定义id的字段，修改用户集合的_id后，这些关联字段必须同步更新，否则查询关联数据时会找不到对应的用户。
• 代码大面积改造的bug风险：现有业务代码里肯定大量依赖自定义的id字段——比如接口返回给前端的用户ID是id，后端通过id查询用户、关联数据。改成用_id后，所有这些地方都要逐一修改，测试不充分的话很容易出现漏改，导致接口报错、业务逻辑异常。
• 自增ID生成的可靠性问题：MongoDB没有内置的自增ID生成机制，原来的自定义id应该是你自己实现的自增逻辑。现在要把这个逻辑迁移到_id上，得确保并发场景下不会生成重复ID，比如用单独的集合存储自增序列，或者借助分布式锁，否则会出现用户ID冲突的严重问题。
• ObjectID特性丢失的影响：原来的ObjectID包含时间戳、机器标识等信息，有些业务可能会用它快速判断文档创建时间，换成数值ID后就没这个便利了，如果有相关逻辑，得提前调整。
• 大集合的性能损耗：如果用户集合数据量很大，批量更新_id的过程会占用大量资源，甚至导致数据库性能下降，影响正常业务。而且修改_id类型后，虽然默认索引存在，但可能需要重新整理索引，这个过程也会耗时。

总的来说，只要你能针对上述风险做好充分的准备——比如制定详细的迁移计划、全面梳理并修改关联代码、确保自增ID生成的可靠性，这个方案是可行的，能有效优化你的数据结构。

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