弹幕不能嵌套在视频文档中，因单条热门视频每分钟弹幕量达数万，嵌套会导致文档频繁重写、突破16MB BSON限制，且无法高效查询指定时间区间；应独立为danmaku集合，用{video_id:1,timestamp:1}复合索引支持范围查询。
弹幕文档为什么不能直接嵌套在视频文档里
音视频点播系统中，弹幕量级远超视频元数据——单条热门视频每分钟可能产生数万条弹幕，而视频文档本身只更新封面、标题等低频字段。若把弹幕数组直接嵌入 video 文档，会触发频繁的文档重写和内存碎片，MongoDB 的 BSON 16MB 限制也很快会被突破。
更关键的是查询性能：用户刷弹幕时通常只拉取某一时段（如第 120–125 秒）的内容，而非整条视频的所有弹幕。嵌套结构无法高效跳过无关时间区间。
实操建议：
- 弹幕必须独立集合，例如
danmaku，不嵌套 - 每个弹幕文档只存必要字段：
video_id（ObjectId）、timestamp（秒级浮点数，如123.45）、content、user_id、style（颜色/位置） - 避免存冗余字段，比如不重复存视频标题或时长——查弹幕时通过
video_id关联即可
如何用 compound index 支持「按视频+时间范围」高效查询
用户拖动进度条时，前端发来的典型查询是：「获取 video_id 为 ObjectId("...")、且 timestamp 在 [180.0, 185.99] 区间的弹幕」。这类查询必须命中索引，否则全表扫描在百万级弹幕下会超时。
错误做法是只对 timestamp 建单字段索引——它无法过滤 video_id，仍要扫描大量无关视频的弹幕。
正确做法是建复合索引：
db.danmaku.createIndex({ video_id: 1, timestamp: 1 })
原因：
- 前导字段
video_id精确匹配，能快速定位到某视频的所有弹幕子集 - 后缀字段
timestamp在子集内有序，支持范围扫描（{$gte: 180, $lt: 186}） - 该索引同时覆盖
find({video_id: ..., timestamp: {$gte: ..., $lt: ...}})查询，无需回表
注意：不要反过来建 {timestamp: 1, video_id: 1}——时间戳全局无序，会导致索引选择性极差。
分段索引（time-based chunking）什么时候需要手动做
MongoDB 本身不提供「自动按时间切片」的索引机制，但当单个视频弹幕量长期超过 500 万条时，即使有复合索引，video_id 值的索引条目也会过于密集，影响 B-tree 查找效率，并增加内存压力。
此时应人工引入分段逻辑，在应用层控制写入路由：
- 将弹幕按时间窗口拆成子集合，例如
danmaku_202405（月粒度）或danmaku_v12345_001（每 10 万条一桶） - 写入前计算所属分片：
const shardKey = Math.floor(timestamp / 3600)（按小时分桶），存入shard_key字段并建索引 - 查询时，先根据请求的时间范围推算出涉及的分片（如 120–125 秒 → 只需查
shard_key: 0），再执行带shard_key过滤的复合查询
这不是必须步骤，仅当监控发现 danmaku 集合的平均文档大小 > 2KB 或查询慢日志中出现 IXSCAN 扫描行数 > 10 万时才启用。
聚合查询弹幕时为什么慎用 $lookup
前端偶尔需要连带返回视频标题、UP 主昵称等信息，容易想到用 $lookup 关联 videos 集合。但实际线上环境这会成为性能黑洞：
- 一次拉取 100 条弹幕，就触发 100 次
videos集合的随机读（即使有_id索引） - MongoDB 的
$lookup不支持对被关联集合使用 hint，无法强制走最优索引 - 如果
videos集合正在重建索引或经历写入高峰，$lookup会放大延迟毛刺
更稳的做法是客户端分两步查：
先查弹幕：db.danmaku.find({video_id: ..., timestamp: {$gte: ..., $lt: ...}}).limit(100)，拿到一批 video_id 列表；
再批量查视频元数据：db.videos.find({_id: {$in: [ObjectId("..."), ...]}})，利用 $in 的索引优化一次性获取。
这个模式把关联逻辑从数据库下推到应用层，可控性更强，也方便加本地缓存（比如用 video_id 查 Redis 缓存标题）。
真正麻烦的不是设计分片或索引，而是弹幕的「时间精度」和「时钟一致性」：播放器上报的 timestamp 是基于前端本地时间，不同设备存在几十毫秒偏差；服务端若不做校准，同一时刻的弹幕在不同用户视角会错位。这个点往往被忽略，直到上线后收到“弹幕飘太快”或“卡在半路”的反馈。
