稀疏数组在用户标签系统中几乎总是不适用：因空数组[]仍使字段存在，无法触发sparse索引跳过；且无法对数组元素建稀疏唯一索引以保证单标签全局唯一。
稀疏数组在用户标签系统中几乎总是不适用
直接说结论：tags 字段如果设计成数组（如 ["vip", "beta-tester"]），就无法设为稀疏索引——因为数组本身是存在的，哪怕为空（[]），字段也不“缺失”。MongoDB 的 sparse: true 只跳过**字段根本不存在或值为 null** 的文档，对空数组完全无效。
更关键的是：你没法对数组元素建“稀疏唯一索引”来约束单个标签的全局唯一性（比如“每个用户只能被标记一次 fraud_risk”）。数组天然支持重复、无序、多值，而稀疏索引机制对此无感知。
- 想用稀疏性节省空间？空数组
[]和["a", "b"]占用的索引体积差异极小，稀疏索引起不到压缩作用 - 想靠稀疏索引加速
{tags: {$exists: false}}查询？这反而会让查询变慢，因为索引里压根不包含这些文档 - 聚合时用
$unwind处理tags数组，一旦某文档tags字段缺失，$unwind会直接丢弃该文档——行为不可控
布尔字段适合明确、互斥、二元状态的标签
像 is_premium、has_verified_email、is_blocked 这类只有 “是/否” 含义的标签，用独立布尔字段 + 稀疏唯一索引是合理选择。但注意：它只适用于“每个标签独立存在、不构成集合”的场景。
- 字段命名必须清晰表达语义，避免
tag_xxx这类泛化命名；否则后期字段爆炸，集合 schema 失控 - 若业务要求“用户可拥有任意组合的 50+ 标签”，硬拆成 50 个布尔字段会导致文档膨胀、写入开销大、查询难以动态构造
-
{is_vip: true}查询能走稀疏索引，但{is_vip: {$exists: true}}不能——前者查值，后者查字段存在性，索引不覆盖
真正适合用户标签系统的方案是嵌套对象 + 索引策略
把标签建模为子文档字段，而非数组或扁平布尔字段：{"tags": {"vip": true, "beta_tester": false, "fraud_risk": null}}。这样既能保持单文档读取优势，又可通过索引精准控制。
- 对高频查询的标签（如
tags.vip）单独建稀疏索引：db.users.createIndex({"tags.vip": 1}, {sparse: true}) - 需要强制“某个标签值全局唯一”时（如仅允许一个用户有
tags.super_admin: true），用复合稀疏唯一索引：db.users.createIndex({"tags.super_admin": 1}, {unique: true, sparse: true}) - 避免在
tags对象里存动态键名（如{"2024_q3_campaign": true}），这会让索引和验证失效；应提前约定键名范围
容易被忽略的边界问题：null 值与缺失字段的行为差异
在标签系统中，"tags": {"vip": null} 和 "tags": {}（即 tags.vip 字段根本不存在）在稀疏索引下表现一致——都被跳过。但应用逻辑常需区分：“显式设为 false” 和 “未设置” 是不同语义。
如果你的业务必须保留这种区分，就不能依赖稀疏性，而要统一用 Boolean 或枚举值（如 "absent"/"false"/"true"），并放弃稀疏索引，改用部分索引（partialFilterExpression）按需覆盖。
