不建议单独用 _id 或 timestamp 作分片键。纯时间戳会导致写入热点，应使用 { "room_id": 1, "timestamp": 1 } 组合分片键，兼顾隔离性与时间局部性，并配以 room_id 在前、timestamp 在后的复合索引支撑高效时间轴查询。
弹幕消息该不该用时间戳当分片键？
直接说结论：**不建议单独用 _id 或 timestamp 作分片键**。MongoDB 分片依赖分片键的离散性与查询局部性，而纯时间戳（如 ISODate("2026-03-12T19:25:00Z")）会导致写入全部打到同一个 chunk（“热点分片”），尤其在直播高峰时，单个分片 CPU 和磁盘 I/O 会迅速打满。
真正可行的组合是：{ "room_id": 1, "timestamp": 1 } —— 先按房间隔离写入域，再在 room 内部用时间排序。这样既保证同一房间消息物理邻近（利于时间轴拉取），又避免跨房间数据混杂导致查询发散。
- 如果只按
room_id分片，时间轴拉取需全量扫描该 room 的所有 chunk，无法利用时间范围下推 - 如果用
timestamp单独哈希分片（如{ timestamp: "hashed" }），时间范围查询会广播到所有分片，延迟陡增 - 生产环境务必禁用单字段升序时间戳分片；Atlas 控制台里看到 “Chunk distribution is highly skewed”，基本就是这个原因
批量拉取弹幕时，find().sort().limit() 为什么越来越慢？
因为没建对索引。时间轴拉取本质是「按房间 + 时间范围取最新 N 条」，典型语句是：db.comments.find({ room_id: "live_123", timestamp: { $gt: ISODate("...") } }).sort({ timestamp: -1 }).limit(50)。若只建了 { room_id: 1 } 索引，MongoDB 无法跳过大量旧文档，sort 阶段必须在内存中完成，容易触发 QueryExceededMemoryLimitNoDiskUseAllowed 错误。
正确做法是建复合覆盖索引：db.comments.createIndex({ room_id: 1, timestamp: -1 }, { background: true })。注意顺序：等值字段 room_id 必须在前，范围字段 timestamp 在后，且方向要和 sort 一致（这里为 -1）。
- 别用
{ timestamp: -1, room_id: 1 }—— 查询时room_id变成 range scan，索引失效 - 如果还要支持按用户查历史弹幕，可额外加
{ user_id: 1, timestamp: -1 }，但别堆砌过多索引，写放大明显 - 本地开发用
mongosh跑explain("executionStats")，确认nReturned≈executionTimeMillis里的totalDocsExamined，否则说明走了全表扫描
按“时间桶”（bucketing）存弹幕，真能扛住高并发写入？
能，但只在特定场景下值得做。所谓 bucketing，是指把同一分钟/5 秒内的多条弹幕合并进一个文档，例如：
{ "_id": { "room_id": "live_123", "bucket": "2026-03-12T19:25:00Z" },
"messages": [ { "user_id": "u1", "text": "666", "ts": ... }, ... ],
"count": 42 }
好处是显著降低文档数量、减少索引条目、缓解分片元数据压力；坏处是更新困难（追加需 $push，删某条得全量读写）、原子性弱、聚合分析变重。
- 适用场景：弹幕只读为主、允许少量丢失、QPS > 5k/秒、且业务能接受「最多延迟 5 秒可见」
- 不适用场景：需实时删除/举报、要按单条弹幕做精准审计、或已有强事务依赖（比如扣币+发弹幕强一致）
- 切记：bucket 字段必须参与分片键，否则跨 bucket 查询会广播；推荐用
{ "room_id": 1, "bucket": 1 }
客户端拉取时，用 changeStream 还是轮询？
对普通观众端，**轮询更稳**；对后台审核/运营系统，changeStream 更合适。changeStream 本质是 oplog 尾部监听，依赖副本集状态和 cursor 保活，网络抖动或消费延迟超 maxAwaitTimeMS 就断连，重连后可能漏掉中间弹幕——而弹幕恰恰不能丢。
轮询方案反而更可控：前端带上次拉取的 last_timestamp，后端用 find({ room_id, timestamp: { $gt: last_ts } }) 拉增量。只要接口响应快、客户端节流合理（比如最小间隔 800ms），体验几乎无差别。
- changeStream 的
resumeAfter依赖 resume token，token 过期（默认 30 分钟）就无法续订，不适合长连接不稳定的移动端 - 如果坚持用 changeStream，请搭配
startAtOperationTime+ 定期持久化 opTime，但这已超出弹幕简单模型范畴 - 轮询记得加
hint()强制走时间索引，防止慢查询拖垮整个分片
时间轴模型最麻烦的从来不是怎么存，而是怎么让“最新 N 条”的语义在分片、索引、读一致性之间不打架。很多人卡在测试环境 OK、上线后查不到新弹幕，八成是分片键和索引没对齐，或者轮询参数没设缓冲窗口。
