MongoDB用户画像应采用宽表设计，将静态属性放根层级、动态标签统一存入tags数组，高频字段单独提取并为tags.key/value建多键索引，更新用$addToSet/$pull避免覆盖，并对大字段另存collection+TTL兜底。
宽表结构用
直接嵌套，别建几十个 collection
用户画像本质是「一个人 + 一堆属性」，MongoDB 的文档天然适合存宽表。硬拆成
、
、
等多个 collection，反而增加聚合成本和事务复杂度。
常见错误是照搬关系型数据库思维，把标签当多对多关系单独建表——结果查一个用户要
四五次，延迟翻倍，还容易因 pipeline 阶段过多触发
错误。
所有静态属性（如
、
、
）直接放在根层级
动态标签统一收进一个字段，比如
：类型为数组，每个元素是带
和
的对象，例如
高频查询字段（如
、
）务必单独提出来，别全塞进
里——否则每次都要遍历数组，无法走索引
数组怎么建索引才不白费力气
直接对
字段建普通索引没用，MongoDB 不会自动展开数组里的对象字段。想按
查，必须用点号路径建多键索引。
典型坑是只建了
，结果
依然慢得像没索引一样——因为这个查询实际匹配的是数组中某个元素的
字段，不是整个
数组。
正确方式：
如果常按单个 key 查所有 value（比如找所有
标签），可加
复合索引，避免排序和内存溢出
注意：多键索引会让文档在索引中占多条记录（数组有几个元素就几条），
过长（>100 项）会显著拖慢写入和索引体积，需定期清理过期标签
动态标签更新用
+
，别用
覆盖整数组
用户标签随时变，比如兴趣从
切到
，或新增
。若每次更新都
，一是网络传大量冗余数据，二是并发写可能丢标签（A 读旧数组 → B 读旧数组 → A 改完写入 → B 改完写入，后者覆盖前者）。
更糟的是用
不去重，导致同一个
出现 5 次，查的时候还得
去重，白白耗内存。
新增唯一标签：
删除某类标签：
替换某 key 的 value：
（两个操作合并进一次 update）
别用
批量加一堆未去重标签——除非你确定来源已排重，否则后续查起来全是噪音
宽表字段膨胀到 16MB 限制前得有兜底策略
MongoDB 单文档硬上限是 16MB，看着大，但用户行为日志一埋、设备列表一塞、历史标签一攒，很容易触线。报错是
，这时候再拆已经晚了。
不是所有字段都该塞进主文档：设备指纹、点击流明细、长文本评论这些低频访问、高体积数据，早该挪出去。
主文档只留强查询字段：ID、基础属性、最新 N 个关键标签（如最近 3 次购买品类）、实时计算指标（
）
大字段另存 collection，用
关联，命名如
，并加 TTL 索引自动过期（比如设备列表保留 90 天）
写入前加校验逻辑：统计
，接近 14MB 就触发告警或自动分流，别等报错才反应
真正难的不是设计宽表，而是判断哪些“动态”其实不该动态——比如“是否领过优惠券”这种布尔态，比存
更省空间也更快查。标签不是越多越好，是够用且能被高效检索才算数。
documentuseruser_tagsuser_behavior_summary$lookupExceeded memory limit for $groupgendercityregister_datetagskeyvalue{ "key": "interest", "value": "ai" }last_login_timeis_viptagstagstagstags.key === "age_group"{ "tags": 1 }find({ "tags.key": "age_group" })keytagsdb.users.createIndex({ "tags.key": 1, "tags.value": 1 })interest{ "tags.key": 1, "tags.value": 1 }tags$addToSet$pull$set"sports""tech""high_spender"$set: { tags: [...] }$push{ key: "interest", value: "ai" }$unwind{$addToSet: { tags: { key: "interest", value: "ai" } }}{$pull: { tags: { key: "interest" } }}{$pull: { tags: { key: "interest" } }, $addToSet: { tags: { key: "interest", value: "ml" } }}$eachBSONObj size: 16793601 (0x1010001) is invalid. Size must be between 0 and 16793600(16MB)rfm_scoreuser_iduser_extended_dataJSON.stringify(doc).length{key:"coupon_status", value:"claimed"}