mongodb全表读取数据，随机I/O vs 顺序I/O分析

使用java读取MongoDB游标数据测试java的MongoDB驱动性能SQL1是{find: user_info, filter: {}}扫描4000万记录耗时32分钟。SQL2是{find: user_info, filter: {data_time: {$lt: {$date: 2025-07-10T16:00:00Z}}}, sort: {depid: 1},耗时3小时。user_info表有4000万条记录字段data_time和depid都建立索引了。sql2查询有索引查询耗时比全表扫描还慢。这是为什么1、explain分析sql1.1COLLSCAN全表扫描{find: user_info, filter: {}}的explain(executionStats)分析结果如下重点是COLLSCAN全表扫描。queryPlanner : { plannerVersion : 1, namespace : usres.user_info, indexFilterSet : false, parsedQuery : { }, winningPlan : { stage : COLLSCAN, direction : forward }, rejectedPlans : [ ] },1.2 IXSCAN扫描{find: user_info, filter: {data_time: {$lt: {$date: 2025-07-10T16:00:00Z}}}, sort: {depid: 1}的explain(executionStats)分析结果如下重点是FETCHIXSCAN。inputStage : { stage : FETCH, filter : { data_time : { $lt : ISODate(2025-07-10T09:30:00Z) } }, inputStage : { stage : IXSCAN, keyPattern : { depid : 1 }, indexName : -1073554321, isMultiKey : false, multiKeyPaths : { depid : [ ] }, isUnique : false, isSparse : false, isPartial : false, indexVersion : 2, direction : forward, indexBounds : { depid : [ [MinKey, MaxKey] ] } } }SQL1和SQL2都是读取集合全部文档4000万条SQL1是31分钟SQL2是3小时读取数量一样说明java序列化数据量相同。1.3 两个sql执行计划对比查询类型执行计划扫描方式排序方式I/O 类型无过滤无排序COLLSCAN顺序扫描无排序顺序I/O过滤排序IXSCAN FETCH按索引顺序扫描索引预排序随机I/O2、原因排查2.1 随机I/O vs 顺序I/O (主要瓶颈)查询1 (32分钟)全表扫描COLLSCAN采用顺序I/O类似连续读取一个大文件磁盘磁头几乎不移动。查询2 (3小时)使用索引扫描IXSCAN后需要1按索引顺序读取文档位置2回表获取完整文档每次读取都是随机磁盘位置→ 产生 4000万次随机磁盘I/O比顺序I/O慢100-1000倍3IXSCAN和FETCH读取数据流程图如下一条记录需要存储两份一份是记录内容B树一份是depid索引B树。IXSCAN扫描索引是顺序扫描数据块扫描出来索引还需要去记录内容B树读取数据然后过滤这个过程是随机读取。所以要触发4000万随机读。这个是主要耗时时间。2.2 索引扫描的隐藏成本虽然索引本身也需要存储到磁盘上有内存缓存但每次索引查找需 CPU 计算每次回表需磁盘寻道4000万次操作累计开销巨大。磁盘效率测试磁盘IO读取性能结果是134MB/s2.3 数学计算解释性能差异假设顺序I/O速度134MB/s随机I/O速度1 MB/s机械硬盘文档大小1KB操作数据量理论耗时全表扫描4000万×1KB 40GB40GB / 134MB/s 305秒索引扫描回表4000万次随机读4000万×1KB / 1MB/s 40,000秒实际比例40,000/305 131倍实际耗时查询132分钟 (≈1920秒)只读取文档内容查询23小时 (≈10,800秒)读取文档内容depid索引读取depid索引数据增加假如读取索引耗时30分钟读取数据才62分钟小于3小时2小时在随机读IO。实测慢5.6倍因HDD/缓存优化了部分随机I/O设置数据存储结构的时候一定要注意文档存储顺序有利于批量读取数据块。