数据冗余不是必须避免的错误，而是需主动控制的权衡项；失控主因是未设边界、未管生命周期、未做读写分离，如嵌入式数组无长度限制会触达16mb文档上限，引用字段缺索引导致全表扫描，类型混用降低压缩率，索引须在数据写入前创建。
直接说结论：数据冗余不是必须避免的“错误”，而是需要主动控制的权衡项；失控的根源往往不是用了嵌入，而是没设边界、没管生命周期、没做读写分离。
嵌入式数组不加长度限制，迟早爆文档上限
很多团队把“用户所有订单”或“课程全部章节”直接 push 进一个数组字段，初期没问题，但一旦单文档逼近 16MB，写操作就会开始失败，错误信息通常是 Document too large。
- 上线前必须对高频增长字段加硬性约束，比如用校验器：
{ $size: { $lt: 50 } }（别用 100，实际建议 ≤30） - 数组超过 20 条后，
$push+$slice的组合更新性能明显下降，尤其在高并发场景下容易堆积锁 - 如果业务真需要“全量历史”，就别塞进主文档——单独建
user_login_logs集合，用user_id索引 + TTL 自动过期
引用字段没建索引，等于没引用
手动引用（Manual Reference）本意是解耦和控冗余，但若 user_id 字段没建索引，查询时实际走的是全表扫描，比嵌入还慢。
-
ObjectId类型必须原生存储，不能存成字符串；否则db.orders.createIndex({ user_id: 1 })建的索引完全无效 - 复合查询如
find({ user_id: ..., status: "paid" })，必须建复合索引：db.orders.createIndex({ user_id: 1, status: 1 }) - 索引一定要在第一批数据写入前创建；已有百万级无索引数据再补，会触发长时间写阻塞
字段类型混用，让压缩率暴跌、缓存浪费严重
同一个 status 字段，一会儿存 "active"，一会儿存 1，WiredTiger 压缩时无法复用字段名和值模板，缓存体积可能多出 30% 以上。
- 数值字段统一用
int32或int64，禁用double存整数 - 字符串字段上线前跑一次清洗脚本：
trim()、转小写、去空格，再配collation: { locale: "en", strength: 2 } - 用聚合查字段分布：
db.users.aggregate([{$project: {fields: {$objectToArray: "$$ROOT"}}}, {$unwind: "$fields"}, {$group: {_id: "$fields.k", count: {$sum: 1}}}], {allowDiskUse: true})，删掉出现频次
模型没随读写压力演进，冗余就从工具变成债务
最初把订单明细嵌入订单文档，是因为每单平均只有 3 条；当某类 VIP 用户平均下单 200+ 次/月，这个设计就该切到引用模式——不是 schema 不能变，而是没人监控变更信号。
- 关键指标要埋点：单文档平均大小、数组字段长度 P95、
db.collection.stats().size/count比值持续 > 5KB - 一旦发现某个用户文档里
orders数组长期 > 100 项，就该触发迁移流程，而不是等报错 - 引用不是终点，而是新起点：拆出去的集合得配好
TTL、分片键、归档策略，否则只是把问题从一个地方挪到另一个地方
最常被跳过的动作，是定期重跑字段统计和文档大小分布——没人看，冗余就只会悄悄膨胀，直到某次扩容或备份失败才暴露出来。
