基于Firestore建模游戏排行榜：score字段是否属单调递增字段？

首先结论：这个限制对你的场景是适用的，但实际影响程度取决于用户score更新的分布情况，具体拆解如下：

核心原理：Firestore的分片热点问题 #

Firestore的分片是按数据的存储键（包括索引字段值）分配的。当大量写入集中在同一个分片时，会触发热点，导致写入吞吐量被限制。官方提到的「避免高频率写入单调递增字段」，本质是防止所有写入都集中到索引的尾部分片——因为递增字段的新值永远比旧值大，都会落到索引最后。

你的场景是否会触发热点？ #

你的score是每个用户文档独立递增，但要注意两个关键点：

• 如果大量活跃用户同时高频更新score，且这些score的新值整体呈现全局递增趋势（比如所有用户的score都在往更高数值走），那么这些写入会集中到score索引的尾部分片，依然会造成热点。
• 如果活跃用户占比低，或者不同用户的score更新区间分散（比如有的用户在低分段更新，有的在高分段更新），热点问题会相对缓和，但高并发下仍有触发风险。

实际优化建议 #

• 非实时排行榜用定时聚合：如果不需要秒级实时的排行榜，每隔几分钟用云函数计算一次全用户排名，把结果存在单独的Ranking集合里，用户查询直接读这个集合，彻底避免score实时更新带来的索引压力。
• 给score加随机偏移：存储score + random(0, 1)这类微小随机值，让相同score的文档分散到不同分片，代价是排序会有微小误差，适合对排名精度要求不高的场景。
• 拆分排行榜：按用户等级、服务器分区维护多个小排行榜，每个小榜的索引写入压力会大幅降低。
• 监控分片负载：在Firestore控制台查看分片的负载情况，如果发现某个分片持续高负载，及时调整写入策略。

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