如何通过比对用户文档数组查询符合条件的游戏文档并减少读操作

下面两种方案都可以满足低读操作的要求，同时规避whereIn的10元素限制：

方案1：用户专属可用游戏子集合（读成本最低） #

• 给每个用户新增一个availableGames子集合，只存储该用户可以正常查看的游戏基础信息。
• 新增游戏时通过云函数触发异步写入：仅给「未被房主屏蔽、也没有屏蔽房主」的用户的availableGames子集合写入该游戏数据。如果用户量级较大，可以仅同步给最近7天活跃的用户，避免无效写入。
• 过期/已结束的游戏通过定时云函数批量从所有availableGames子集合中清理即可，存储冗余可控。
• 查询时直接拉取当前用户的availableGames集合，1次查询就能拿到所有符合条件的结果，读次数等于返回的游戏数量，无任何额外浪费。

方案2：分批查询+轻量过滤（开发成本最低） #

保留你之前设计的matchmaking集合，调整查询逻辑即可：

• 第一步：所有查询先加where("blockedUserIds", "array-not-contains", "当前用户ID")的过滤条件，先过滤掉所有房主已经屏蔽了你的游戏，拿到初始候选池。
• 第二步：把当前用户自己的blockedUsers屏蔽列表拆分为每9个元素一组，每组对应一个查询，加上where("createdBy", "not-in", 分组数组)的过滤条件，和第一步的条件组合后分批查询。
• 第三步：合并多批次的查询结果，就是完全符合双方未屏蔽要求的游戏列表。
• 该方案的读次数仅为「屏蔽列表长度/9」向上取整，就算你屏蔽了100个用户，也只需要12次查询，远低于逐游戏校验的读成本。

补充维护逻辑：每次用户更新自己的屏蔽列表时，通过云函数同步更新该用户创建的所有游戏的blockedUserIds数组即可，更新成本极低。

内容的提问来源于stack exchange，提问作者anonymous-dev