冷热分离必须拆表而非加标记，因MongoDB WiredTiger按页加载数据，大字段与小字段同页会导致I/O放大；热表存轻量字段供高频查询，冷表独立存储大字段并异步加载，否则无法降低延迟。
直接读取含大对象（如 Base64 图片、长文本、二进制附件）的文档时，即使只查几个小字段，MongoDB 仍会把整条 BSON 文档从磁盘/内存加载进来——大字段拖慢 I/O、网络传输和内存解析，这是延迟主因。冷热分离不是“加个字段标记”就能生效，关键在查询路径是否绕开大字段存储位置。
大对象字段导致读取变慢的真实链路
MongoDB 存储引擎（WiredTiger）按 page 组织数据，一个文档跨多个 page 时，哪怕只读 _id 和 title，只要它们和大字段在同一页或相邻页，WiredTiger 就得把整页 load 进 cache；若 cache 不足，还会触发 page faults/sec 上升，进一步拉高延迟。这不是“网络慢”，而是底层存储访问放大了。
- 大字段未被索引时，
find({ _id: "xxx" }, { title: 1 })仍需反序列化整个文档才能提取title - 使用
$project或字段投影（{ title: 1, _id: 0 }）仅减少网络传输量，不减少磁盘 I/O - 聚合管道中用
$unset或$project删除大字段，对单文档查询无加速效果——它发生在数据取出之后
冷热分离必须拆表，不能只靠字段命名
所谓“冷热分离”，本质是物理隔离：高频访问字段（热）和低频大字段（冷）必须存于不同集合，否则无法规避 I/O 放大。常见错误是把大字段塞进同一个文档加个 isCold: true 标记，这毫无作用。
- 热表（如
user_profile）只存_id、name、email、updated_at等轻量字段，所有业务查询默认走这张表 - 冷表（如
user_attachments）以user_id为外键，存user_id、file_type、content（大字段）、created_at，仅在用户点开“附件”时按需查 - 应用层需主动维护两表一致性：写大字段时，先写热表（更新
has_attachment: true），再写冷表；删时同理
读取冷数据时避免阻塞主线程
冷表查询本身可能慢（尤其带大字段），但不应让其拖垮整个接口。必须异步化或降级处理：
- Java/Spring 中，用
@Async或CompletableFuture异步查冷表，主流程不等结果直接返回热字段 - Python 中，用
asyncio.to_thread()包裹collection.find_one()，避免阻塞 event loop - 前端可先渲染热字段，再发独立请求加载附件预览图/元信息，HTTP Cache 头设短 TTL 避免重复拉取
- 绝不允许在事务中同时读热表+冷表——WiredTiger 事务锁粒度是文档级，冷字段加载慢会延长锁持有时间，引发写冲突
冷表索引与连接池要单独配
冷表查询模式和热表完全不同：热表高频点查 _id，冷表常按 user_id + file_type 范围查。连接池也不能混用：
- 冷表集合必须建复合索引：
db.user_attachments.createIndex({ user_id: 1, file_type: 1, created_at: -1 })，避免全表扫描 - Spring Boot 中，为冷表配置独立
MongoTemplateBean，连接池参数调低（如connections-per-host="20"），防止冷查询耗尽连接拖累热查询 - 监控重点不是冷表 QPS，而是其平均响应时间和
cursor.exhaust是否频繁——若冷表查询常超 5s，说明大字段已影响 WiredTiger page 缓存效率，该考虑对象存储外置了
冷热分离真正起效的前提，是业务能接受“热字段秒级返回，冷字段异步加载”的交互节奏。如果某个接口必须同步返回全部字段，那拆表只是把延迟从“一次慢”变成“必然慢”，此时应直接把大字段移出 MongoDB，存到 S3/OSS 并只保留 URL 字段。
