宽表建模更合理：统一用user_events集合，以session_id为单位存事件数组，为user_id、session_start、events.event_type等路径建精确索引，并用$push+$slice控制数组长度防膨胀。
用户行为埋点数据在 MongoDB 中不适合按“事件类型建 collection”或“每个字段建独立 collection”，宽表建模是更合理的选择——把高频共现的字段打平到单文档，用嵌入数组存变长行为，同时为查询路径建对路的索引。
为什么不能按 event_type 拆 collection
常见错误是为 click、view、search 各建一个 collection。结果是：查某个用户的完整行为流，得发 5+ 次查询；做漏斗分析时必须 $lookup 关联，pipeline 超过 3 个 stage 就容易触发 Exceeded memory limit for $group 错误；写入压力分散但读取成本飙升，尤其在实时看板场景下延迟不可控。
正确做法是统一收口到 user_events 集合，用 event_type 字段区分行为类型，再靠索引和投影控制性能。
- 所有埋点共用一套基础字段：
user_id、session_id、timestamp、event_type、page_url、device_info（嵌套对象） - 动态字段（如
search_keyword、product_id、duration_ms）作为可选字段直接写入文档，不强求每条都有 - 避免用
properties: { k1: v1, k2: v2 }这种泛化结构——它让索引失效、聚合难写、Schema 检查失能
如何设计嵌套行为数组
当一个用户单次会话产生多条行为（比如一次浏览含 3 次点击 + 1 次加购），不要把每条行为拆成独立文档存，也不要全塞进一个大数组里再用 $unwind 查——那样会严重拖慢写入和索引体积。
更实用的方式是：以会话（session_id）为单位建文档，把该 session 内所有事件存为 events 数组，每项是完整行为对象：
{ "_id": "sess_abc123", "user_id": "u_456", "session_start": ISODate("2026-10-20T14:00:00Z"), "events": [ { "event_type": "view", "timestamp": ISODate("2026-10-20T14:00:05Z"), "page_url": "/product/1001", "ref_url": "/home" }, { "event_type": "click", "timestamp": ISODate("2026-10-20T14:00:12Z"), "element_id": "btn_add_to_cart", "product_id": "p_1001" } ] }
这样设计的好处：
- 单次读取就能拿到完整会话行为，适合做 session-level 分析（如停留时长、跳出率）
- 写入是原子的，不会因网络重试导致行为丢失或重复
- 可以对
events.event_type和events.timestamp建多键索引，支持按类型+时间范围快速过滤
哪些字段必须单独提出来建索引
别指望靠 { "events": 1 } 这种索引加速查询——MongoDB 不会自动展开数组内容。真正有效的索引必须精确到点号路径。
以下字段建议单独提取并建索引：
-
user_id：高频查询入口，建普通索引{ "user_id": 1 } -
session_start：用于按时间段筛选会话，建 TTL 索引或范围查询索引{ "session_start": -1 } -
events.event_type+events.timestamp：复合多键索引{ "events.event_type": 1, "events.timestamp": -1 }，支撑 “查某用户最近 10 条 click 行为” 类查询 -
events.product_id：如果加购、下单等事件带商品 ID，单独建稀疏索引{ "events.product_id": 1 }（加sparse: true避免为 null 字段建索引条目）
注意：events 数组长度超过 50 项后，写入延迟和索引膨胀会明显上升，此时应考虑按天分片（如 user_events_20261020）或启用分片集群。
怎么避免大文档和索引爆炸
埋点数据天然有写多读少、字段膨胀快的特点。不做约束的话，一个 session 文档可能很快突破 16MB 上限，或者因 events 数组过大导致索引条目数翻倍增长。
实操中要主动设边界：
- 服务端入库前截断
events数组，保留最近 200 条（或按时间窗口保留最近 2 小时） - 对低价值字段（如
user_agent全量字符串）只存哈希或截断前 64 字符，避免索引 bloating - 把原始日志级字段（如完整 network trace、full DOM snapshot）另存到
raw_logs集合，并用 TTL 自动过期（如{ "expireAfterSeconds": 86400 }） - 定期运行聚合任务清理过期 session：
db.user_events.deleteMany({ session_start: { $lt: ISODate("2026-10-19T00:00:00Z") } })
最易被忽略的一点是：不要在应用层拼接 events 数组再整条 $set 更新——并发写会覆盖彼此。改用 $push + $slice 组合控制长度，例如：
db.user_events.updateOne( { _id: "sess_abc123" }, { $push: { events: { $each: [newEvent], $slice: -200 } } } ) 
