1. 问题背景：当数据量遇上内存瓶颈
在我们团队最近处理的电商用户行为日志场景中，MongoDB集合的文档量已经突破2亿大关。每当执行全表扫描查询时，服务器内存就像被吸血鬼咬住一样，32GB的内存转眼就被吃光。特别是在执行需要排序的分页查询时，db.collection.find().skip(1000000).limit(100)这样的操作直接把内存占用率推上90%红线。
背后的技术原因是WiredTiger存储引擎的默认缓存机制。MongoDB默认会分配50%的可用内存给WiredTiger缓存（但不超过256GB），当执行需要排序的大范围查询时，系统会尝试将整个工作集加载到内存。这就好比试图把一头大象塞进冰箱，结果自然是内存溢出和查询超时。
2. 分页策略的优化之道
2.1 传统分页的死亡陷阱
// 使用MongoDB.Driver的典型错误分页示例
var collection = database.GetCollection<BsonDocument>("user_logs");
var filter = Builders<BsonDocument>.Filter.Empty;
var sort = Builders<BsonDocument>.Sort.Descending("created_at");
// 当skip值达到百万级时，内存开始报警
var result = collection.Find(filter)
.Sort(sort)
.Skip((pageNumber - 1) * pageSize)
.Limit(pageSize)
.ToList();
这种基于Skip的分页方式在数据量较小时表现良好，但当遇到海量数据时就像在流沙上盖房子。MongoDB需要遍历并丢弃前N条记录，这种操作的时间复杂度是O(N)，既吃内存又耗CPU。
2.2 基于范围的分页术
// 使用游标式分页的正确姿势
var lastRecord = GetLastRecordFromPreviousPage(); // 获取上一页最后一条记录
var filter = Builders<BsonDocument>.Filter.Gt("_id", lastRecord["_id"]);
var sort = Builders<BsonDocument>.Sort.Ascending("_id");
var result = collection.Find(filter)
.Sort(sort)
.Limit(pageSize)
.ToList();
// 记录本页最后一条的ObjectId用于下一页查询
var lastId = result.LastOrDefault()?["_id"];
这种基于范围查询的分页方式，相当于给每个页面设置了地理围栏。需要确保查询字段（通常用_id或时间戳）上有合适的索引，查询复杂度直接降到O(logN)，内存占用减少约70%。
3. 缓存策略的三板斧
3.1 内存配置调优
修改MongoDB配置文件（mongod.conf）：
storage:
wiredTiger:
engineConfig:
cacheSizeGB: 4 # 根据服务器总内存动态调整
这个配置就像给MongoDB戴上了节流器，强制限制缓存大小。但要注意不能设置得过小，否则会导致频繁的磁盘IO。通常建议保留总内存的20%-30%给系统和其他服务。
3.2 查询结果缓存方案
// 使用MemoryCache做一级缓存（需引用Microsoft.Extensions.Caching.Memory）
var cacheKey = $"query_cache_{hashedQuery}";
if (!memoryCache.TryGetValue(cacheKey, out List<BsonDocument> cachedData))
{
cachedData = ExecuteMongoQuery(query);
memoryCache.Set(cacheKey, cachedData, TimeSpan.FromMinutes(5));
}
// 使用Redis做二级缓存（需引用StackExchange.Redis）
var redisDb = redis.GetDatabase();
var redisData = redisDb.StringGet(cacheKey);
if (!redisData.IsNull)
{
return DeserializeFromBson(redisData);
}
这种分层缓存架构就像给数据库加了缓冲带。需要注意缓存过期策略，对于频繁更新的数据建议设置1-5分钟的短缓存，静态数据可以缓存数小时。
4. 应用场景全解析
4.1 日志分析系统
某金融公司的交易日志系统每天新增500万条记录。使用范围分页配合TTL索引后，月度报表生成时间从45分钟缩短到8分钟，内存峰值下降60%。
4.2 电商商品搜索
当用户按价格区间筛选商品时，通过组合索引（品类+价格）的游标分页，使得在5000万商品中的分页响应时间稳定在200ms以内。
4.3 物联网设备监控
对10万台智能电表的实时状态查询，采用Redis缓存最近5分钟数据+MongoDB持久化存储的方案，查询吞吐量提升3倍。
5. 技术方案的AB面
5.1 分页策略对比
| 方案类型 | 优点 | 缺点 |
|---|---|---|
| 传统Skip分页 | 实现简单，页码自由跳转 | 大数据量性能差，内存占用高 |
| 游标分页 | 性能优异，资源消耗低 | 无法直接跳转指定页码 |
| 时间窗口分页 | 适合时序数据 | 需要精确的时间索引 |
5.2 缓存方案选择
在最近的项目中，我们发现：
- 内存缓存命中率可达85%，但服务器重启会导致缓存雪崩
- Redis缓存平均响应时间2ms，但网络抖动时可能超时
- MongoDB自身缓存命中率约70%，但对内存压力较大
6. 避坑指南：血泪教训总结
索引的双刃剑：某次给20个字段都建了索引，结果写入性能下降70%。建议遵循"查询模式驱动索引设计"原则。
缓存的失效风暴：曾经因为同时过期3000个缓存项，导致数据库瞬间被打挂。解决方案是给缓存过期时间添加随机扰动值。
分页的连续性陷阱：在游标分页中，如果中间有数据删除，可能导致分页断裂。解决方法是用逻辑删除标记替代物理删除。
内存监控的必修课：使用
db.serverStatus().wiredTiger.cache命令定期检查缓存命中率，当命中率低于90%时就需要考虑扩容或优化。
7. 总结：没有银弹，只有组合拳
经过多个项目的实践验证，我们总结出一个黄金组合方案：
- 对核心查询建立精准的复合索引
- 采用游标分页为主，传统分页为辅的策略
- 构建三级缓存体系（内存->Redis->MongoDB）
- 实施动态内存监控与自动扩容机制
某跨境电商平台采用这套方案后，在"黑色星期五"大促期间，订单查询接口的P99延迟从850ms降至120ms，服务器成本反而降低25%。这告诉我们：面对海量数据查询，优化不是单选题，而是需要多种策略的有机组合。就像中医调理需要君臣佐使，技术优化也需要各种方案的协同配合。