快照查询慢的根本原因是底层扫描范围过大，即使启用readConcern: "snapshot"也需依赖索引（如updatedAt升序索引）快速过滤，否则仍全表扫描；分片键若未对齐时间查询模式，会加剧跨分片广播。
快照查询为什么慢？不是读关注的问题，是底层扫描范围太大
启用 readConcern: "snapshot" 只保证一致性，不加速查询本身。如果集合没索引、数据量大、时间戳字段未建索引，MongoDB 仍会全表扫描匹配时间点的文档——哪怕你只查过去 5 秒的数据。快照隔离靠的是存储引擎（WiredTiger）的多版本快照机制，但定位“哪个文档在某时间点存在”，还得靠索引快速过滤。
必须给 ts 或 updatedAt 字段建索引，且注意排序方向
历史快照查询常基于时间范围（如 { updatedAt: { $gte: ISODate("2026-04-10"), $lt: ISODate("2026-04-11") } }）。若 updatedAt 没索引，或建了但顺序和查询不匹配，性能会断崖下跌：
- 升序索引
{ updatedAt: 1 }对$gte/$lt范围查询最友好，B-tree 可高效跳转起始位置 - 降序索引
{ updatedAt: -1 }在配合.sort({ updatedAt: -1 }).limit(10)时更优，但纯范围查询无优势 - 避免复合索引把时间字段放在第二位（如
{ status: 1, updatedAt: 1 }），除非查询一定带status等前导条件
验证是否命中索引：执行 db.collection.find(...).explain("executionStats")，检查 executionStats.nReturned 是否接近 executionStats.totalDocsExamined —— 若二者相差巨大，说明索引失效或未用上。
分片键不能只图均匀，得和快照查询模式对齐
分片本身不提升单次快照查询速度，反而可能因跨分片广播请求拖慢。关键在于让查询能路由到少数分片：
- 若按时间范围查历史快照（比如查“昨天所有变更”），分片键应包含时间字段，例如
{ shardKey: { updatedAt: "hashed" } }不行，{ shardKey: { updatedAt: 1, _id: "hashed" } }也不理想；更合适的是{ shardKey: { updatedAt: "date", tenantId: "hashed" } }（需 MongoDB 6.0+ 支持 date 分片） - 更现实的做法：用
updatedAt的年月作为分片前缀，如{ shardKey: { tsPrefix: 1, _id: "hashed" } }，应用层写入时计算tsPrefix: "2026-04"，查询时带上该前缀，就能精准落到 1 个分片 - 绝对避免用纯随机值（如
UUID）作唯一分片键，否则每次快照查询都打散到全部分片
system.profile 不是实时快照，别把它当查询加速手段
db.setProfilingLevel(2) 开启的 system.profile 是诊断工具，记录操作元信息（耗时、扫描文档数等），它本身不参与快照读取逻辑，也不影响查询性能。有人误以为“开了 profile 就能加速历史查询”，这是混淆了监控与执行路径。真正影响快照查询延迟的，只有三样东西：时间字段索引、分片路由效率、WiredTiger 快照查找开销（后者通常固定，不可调）。
