Firestore按字母顺序设置文档ID是否会导致热点或效率问题？

使用A-Z共26个字母作为users集合的固定文档ID，不会触发官方文档提到的单调递增连续ID导致的写入热点问题，但这个设计本身存在非常明显的性能、扩展性缺陷，完全不推荐在生产环境使用。

为什么不会触发官方提到的热点问题 #

官方警示的单调递增ID（比如Customer1/Customer2/Customer3这类顺序生成的ID）热点，核心成因是高并发写入场景下，所有新创建的文档ID会按字典序持续落在ID空间的最尾部，导致所有写入流量全部打到同一个存储分片上，超出分片承载上限后引发延迟飙升、请求限流。
而你设计里的26个字母ID对应的是提前创建好的固定父文档，不存在持续向ID序列尾部新增文档的行为，自然不会触发这类连续新增带来的热点。

这个设计存在的实际问题 #

• 流量倾斜导致的人为热点：用户名首字母的自然分布极度不均匀——不管是中文拼音还是英文场景，S、L、Z等首字母对应的用户量，往往是X、Q等冷门首字母的几十甚至上百倍。高并发读写时，热门首字母对应父文档下的子集合流量会远高于其他分片，一旦超出单分片的性能阈值，一样会出现延迟升高、请求被限流的问题，和你想要规避的热点问题本质没有区别。
• 分片无法自动扩容：Firestore中子集合的所有数据是和所属父文档绑定在同一个存储分片组内的，不会随着流量增长自动拆分到更多分片。单分片组本身有固定的性能上限（约每秒500次写入、每秒1000次读取），热门首字母对应的子集合流量触顶后没有任何自动扩容的空间，只能手动拆库拆数据。
• 后续扩展成本极高：如果后续某个首字母对应的用户量、流量超过单分片承载能力，你只能手动做数据拆分——比如把S开头的用户再拆成Sa-Sm、Sn-Sz两个分片，需要做全量数据迁移、线上双写兼容、流量切流等复杂操作，运维成本极高。

推荐的替代方案 #

• 直接将所有用户文档存储在users根集合下，使用Firestore自动生成的随机文档ID即可。这类随机ID会均匀散列在所有存储分片上，Firestore会自动根据流量做分片扩容，从根源上避免热点问题，不需要你手动实现任何分片逻辑。
• 如果你需要按用户名首字母做筛选查询，只需要给用户名字段添加对应索引即可，查询性能和你手动拆分子集合没有差异，还能支持更灵活的前缀匹配、模糊搜索等需求，完全没有必要手动按首字母拆分父文档。

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