Subset Pattern 是一种通过预存高频子集来优化长数组查询性能的设计模式，适用于读多写少、仅需展示最新少量数据的场景。
Subset Pattern 是什么，它真能解决长列表加载慢？
能，但只在特定场景下有效——当你的文档里嵌套了超长数组（比如用户收藏的 10 万条商品 ID），而每次查询只需要展示前 20 条或按时间倒序取最新几条时，Subset Pattern 就是比「全量加载 + 应用层截断」更靠谱的选择。它的核心不是减少数据量，而是把高频访问的子集提前固化到字段里，绕过对大数组的扫描和排序。
怎么设计 Subset 字段：三个关键字段缺一不可
别只加一个 recent_items 数组就完事。实际部署中必须同时维护：
-
items_count：记录原始数组总长度，用于分页提示或“查看更多”逻辑判断 -
subset_items：存放最新 N 条（如 50 条）的精简数据（ID + 关键字段，非全量文档） -
subset_updated_at：标记该子集最后更新时间，方便缓存失效或增量同步校验
示例文档结构：
{
"_id": ObjectId("..."),
"user_id": "u123",
"items_count": 98421,
"subset_items": [
{ "item_id": "i772", "title": "无线耳机", "added_at": "2024-05-01T10:22:00Z" },
{ "item_id": "i881", "title": "机械键盘", "added_at": "2024-04-29T15:11:00Z" }
],
"subset_updated_at": "2024-05-01T10:22:00Z"
}
更新 Subset 的时机和陷阱：别在写入时实时重算
每次 push 新元素都去 $slice 整个数组再重写 subset_items？性能会断崖式下跌。正确做法是懒更新 + 异步兜底：
- 插入新项时，只用
$push追加到原始数组，并用$set更新subset_items.0和subset_updated_at（即只插一条到子集头部） - 当
subset_items.length < 50，直接$push到子集；超过后，改用$position: 0+$each插入并配合$slice: 50原地裁剪 - 定期用后台任务（如每小时）跑一次聚合管道，校准
subset_items与真实最新数据的一致性，防止因异常中断导致子集陈旧
错误示范：db.users.updateOne({ _id }, { $push: { all_items: newItem }, $set: { subset_items: { $slice: [ "$all_items", -50 ] } } }) —— $slice 不能在 $set 里直接引用数组字段，会报 Invalid $set :: caused by :: specification contains invalid expression。
查询时如何安全 fallback 到全量数组
Subset 只是优化手段，不是数据源替代。前端请求 “加载更多” 超过 50 条时，必须平滑降级：
- 先查
subset_items满足首屏；若需第 51–100 条，再发第二条查询，用$slice: [ "$all_items", 50, 50 ]从原始数组中切片（注意：这仍会加载整个数组进内存，仅适用于读多写少且数组不超 10 万） - 永远在应用层校验
items_count和实际返回条数，避免因子集未及时更新导致“显示已加载全部，实际还差几百条”这类体验 bug - 如果原始数组经常变动且长度 > 50 万，就别硬扛了——这时候该拆成独立集合（
user_items），用user_id+created_at复合索引分页查
真正容易被忽略的是：Subset Pattern 的有效性高度依赖业务读写比例和更新频率。如果用户每秒新增 10 条收藏，又要求子集严格实时，那这个模式反而会成为瓶颈。
