MongoDB中_id字段的哈希索引是否比默认B树索引更快？

先直接给结论：MongoDB自动生成的ObjectId分布足够均匀，完全能让哈希索引达到**O(1)**的平均时间复杂度。

为什么ObjectId分布这么均匀？ #

ObjectId的结构天生就为分散性设计：

• 前4字节是秒级时间戳，新生成的ID会随时间有序推进，不会扎堆；
• 中间3字节是机器标识，集群里不同机器的ID天然分散；
• 再2字节是进程ID，同一机器上不同进程的ID也会区分开；
• 最后3字节是自增计数器，同一秒内同一进程生成的ID会递增，但这部分占比极小，根本不会破坏整体的分散性。

这种结构让ObjectId在全局范围内的分布非常均匀，几乎不会出现大量ID挤在同一个哈希桶的情况。

哈希索引O(1)的实际表现 #

哈希索引的O(1)是平均时间复杂度，极端哈希冲突下会退化，但ObjectId的设计从根源上把冲突概率压得极低：

• MongoDB的哈希函数对ObjectId的计算会把它均匀映射到各个哈希桶；
• 就算出现少量冲突，MongoDB也会用链表等方式处理，但因为分布均匀，这种情况极少发生，实际查询性能几乎就是理论上的O(1)。

额外提醒：哈希索引vs B树索引 #

虽然哈希索引等值查询更快，但它不支持范围查询、排序这些操作。如果你主要是查单个_id的等值查询，用哈希索引确实更高效；但如果需要按时间范围筛选_id（比如查某段时间创建的文档），那B树索引才是正确选择——毕竟ObjectId的时间戳部分在B树里是有序的，能高效处理范围查询。

内容的提问来源于stack exchange，提问作者Bear Bile Farming is Torture