Google Firebase Firestore默认索引采用何种数据结构？求同类方案参考

作为常年跟Firestore和数据库索引打交道的老开发，我来拆解下我推测的Firestore默认索引底层数据结构——毕竟官方没明说，但从它的核心行为特征倒推，还是能摸出不少门道的。

先锚定已知的关键边界：Firestore默认给所有字段（包括嵌套字段、数组元素）自动建索引，但这些默认索引仅支持等值查询，范围/排序查询必须手动创建复合索引。从这个核心规则出发，它的默认索引绝对不是B树/B+树这类有序结构——毕竟B树天生就是为范围查询优化的，要是默认用了，完全没必要藏着不让用户用范围查询。

我推测它的默认索引核心是以下两种结构的组合：

1. 单字段哈希索引（Per-Field Hash Index） #

这是默认索引的核心基础：

• 对每个字段（比如name、address.city，甚至数组tags里的每个元素），维护一个哈希表：键是字段的具体值，值是匹配该值的所有文档ID的集合（一般用有序集合或者链表存储，方便去重和快速遍历）。
• 为啥选哈希表？因为等值查询的时间复杂度是O(1)（理想情况下无哈希冲突），完美匹配Firestore默认索引的核心需求——快速定位所有等于某个值的文档。
• 数组字段的特殊处理：Firestore会把数组里的每个元素单独作为哈希键，把当前文档ID关联到每个元素的哈希条目里。这也是为啥array-contains查询能直接用默认索引的原因——本质还是等值匹配。

2. 文档ID的反向索引（Reverse Index for Document IDs） #

这是个辅助性的结构，用来解决更新/删除的效率问题：

• 每个文档ID会反向关联到它所有字段的索引条目里。比如你更新了文档的name字段，从"Alice"改成"Bob"，系统能通过文档ID快速找到之前"Alice"对应的哈希条目，移除这个文档ID，再把它加入"Bob"对应的条目里，不用全表扫描所有索引。

为什么排除B树？ #

官方明确说默认索引不支持范围查询，而B树的最大优势就是有序性，能高效处理</>/orderBy这类操作。如果默认用了B树，那完全可以开放范围查询功能，没必要让用户手动去建复合索引。这反过来坐实了默认索引是无顺序的哈希结构，只专注优化等值匹配场景。

补充：针对排序的小优化 #

当你做where("name", "==", "Alice").orderBy("__name__")这类查询时，Firestore能直接返回按文档ID排序的结果，不用额外排序。这说明每个哈希条目里的文档ID集合是有序存储的（比如用跳表或者有序数组），这样取出时直接就是有序的，省了排序开销。

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