MongoDB为何采用字符串类型ObjectID作为_id而非数值类型？

你这个问题的前提就不成立：MongoDB 默认的 _id 对应的 ObjectID 原生根本不是字符串存储的。
它是BSON规范里专门定义的12字节定长二进制类型（类型标识为7），实际存储占用只有12字节，远不到你说的24字节字符串的体量——你平时在命令行、可视化工具里看到的24位十六进制字符串，只是客户端做的可读化转换，和IP地址展示成点分十进制字符串、但实际存的是4字节整数是一个道理，展示格式不等于底层存储格式。

为什么不用8字节数值类型存ObjectID？核心原因是8字节根本装不下分布式无冲突ID需要的信息 #

MongoDB设计ObjectID的核心目标是：不需要中心化发号节点，分布式集群里任意机器、任意进程本地生成的ID全局唯一，还能近似按生成时间排序。为了实现这个目标，12字节的结构是精打细算凑出来的：

• 前4字节：Unix时间戳（秒级），足够用到2106年，同时保证ID大致按生成时间递增
• 中间3字节：所在机器的唯一标识，避免不同机器生成ID撞车
• 接下来2字节：生成ID的进程ID，避免同一台机器上不同进程生成ID撞车
• 最后3字节：进程内的自增计数器，保证同一进程同一秒内生成的ID不重复，单进程每秒最多支持生成1600多万个不重复ID
  这些字段加起来刚好12字节，已经超过了8字节（64位）整数的最大存储容量。如果硬要压缩到8字节，势必要砍某个字段的长度：要么缩短时间戳长度导致ID几十年后就耗尽，要么缩短机器/进程标识位导致分布式场景下ID冲突概率飙升，要么缩短计数器长度导致单进程每秒生成ID的上限太低，哪个代价都接受不了。

你提到的性能优势在实际场景里根本不成立 #

你说数值运算比字符串快，这个结论本身没问题，但不适用于原生ObjectID：

• 首先原生ObjectID是定长二进制，不是变长字符串，比较大小的时候是按固定字节顺序逐位对比，和整数比较的逻辑几乎没有区别，性能差距可以忽略
• 其次ObjectID的字节顺序本身就是按「时间戳>机器标识>进程ID>计数器」的优先级排列的，不需要额外解析就能直接比较顺序，天生支持按插入时间排序，甚至不需要额外存创建时间字段
• 如果真用8字节整数做分布式ID，反而要额外处理跨架构的大小端兼容问题：不同CPU架构、不同编程语言对整数的字节序解析规则不一致，很容易出现跨节点读ID解析错误的问题，而ObjectID的字节序是规范写死的，不存在这个兼容问题。

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