Firestore复合索引200上限疑问：嵌套多用户结构是否占用额度？

先直接打消你的顾虑：你的嵌套多用户结构根本不会因为用户或角色数量多而触及200复合索引上限——因为Firestore的复合索引计数规则是看「索引定义的数量」，不是看用户/文档的数量。下面我拆解清楚：

核心规则：复合索引按「定义」计数，和实例数量无关 #

Firestore的200复合索引上限，是指整个数据库中不同的复合索引定义总数，而不是每个用户、每个文档对应的索引数量。

举个例子：如果你的角色存在users/{userID}/characters这个子集合里（这也是我推荐的结构，后面说原因），你为这个子集合创建一个「按strength升序排序」的复合索引——这个索引只算1个，不管你有1个用户还是10000个用户，所有用户的characters子集合查询都会共享这个索引，不会额外占用名额。

针对你的场景的具体分析 #

情况1：角色存在子集合（推荐方案） #

如果每个用户的角色都存在users/{userID}/characters子集合中（每个角色是独立的文档），那么：

• 你需要的每个排序/过滤组合，只需要创建一次索引：
  • 要按strength排序？创建1个索引（strength ASC/DESC）
  • 要按speed排序？再创建1个索引
  • 要同时按strength升序+speed降序过滤排序？再创建1个组合索引
• 这些索引的数量是固定的，和用户数、角色数完全无关。哪怕你有10万用户，每个用户有1万角色，只要你需要的索引组合不超过200个，就不会触及上限。

另外，这种子集合结构还能避免单个文档过大的问题（Firestore单文档最大1MB，数千个角色嵌套在用户文档里肯定会超），同时支持更灵活的查询。

情况2：角色嵌套在用户文档的数组中 #

如果你的characters是用户文档里的数组字段，那：

• 如果你只是获取用户文档后在客户端对数组排序，完全不需要任何复合索引，自然不会碰上限。
• 如果你想在服务器端对数组进行过滤+排序（比如找某个用户下strength>100的角色并排序），Firestore对这种数组内字段的服务器端查询支持有限，通常只能客户端处理，同样不会用到复合索引。

最后提醒 #

• 优先选择子集合存储角色，这是Firestore处理大量关联数据的标准模式。
• 统计你实际需要的索引组合：比如单独按strength、speed、stamina排序是3个索引；如果需要strength+speed、strength+stamina等组合排序，每个组合算1个。只要总数不超过200，就完全没问题。

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