Spring Boot操作MongoDB查询越来越慢，分页取百万文档后期耗时陡增

• 索引匹配效率低：当前仅为createdDate字段创建了单字段索引，而实际查询方法findByCreatedDateLessThanAndStatusInAndFlagNot包含三个过滤条件，MongoDB通过createdDate索引筛选出符合日期的文档后，需要在内存中额外过滤status和flag条件。前期未标记的文档占比高，过滤速度快；后期绝大多数符合日期条件的文档都已被标记为flag=true，需要扫描数万甚至数十万条已标记文档才能凑齐100条符合条件的结果，查询耗时指数级上升。
• 查询条件不合理：使用flagNot true的否定查询，否定条件本身无法高效利用索引，进一步降低了过滤效率。
• 重复扫描开销：每次固定查询第0页，相当于每次查询都要重新扫描整个符合createdDate条件的数据集，无法复用之前的扫描结果，越往后需要跳过的无效已标记文档越多。

• 重建适配查询的复合索引：按照「等值匹配字段在前、范围匹配字段在后」的原则，创建复合索引{status: 1, flag: 1, createdDate: 1}，让三个查询条件都可以直接通过索引过滤，不需要内存扫描额外文档。如果业务允许，将flag字段的默认值设置为false，把查询条件从flagNot true改为flag = false的等值查询，索引效率会进一步提升。
• 调整查询方法定义：将Spring Data MongoDB的查询方法从findByCreatedDateLessThanAndStatusInAndFlagNot改为findByCreatedDateLessThanAndStatusInAndFlagIs，参数传入false，替换否定查询为等值查询。
• 改用游标流式批量查询：放弃分页查第0页的方案，使用MongoTemplate的streamQuery方法开启游标查询，设置batchSize=100，游标会持续从服务端拉取符合条件的文档，不需要每次重新发起全量扫描，大幅降低重复开销。
• 批量执行更新操作：每次拉取到100条文档后，收集所有文档的_id列表，使用updateMulti方法批量更新这批文档的flag为true，不要逐条更新，减少和MongoDB的交互次数。
• 拆分查询范围：如果总数据量过大，可以按照createdDate将整个查询任务拆分为多个小的时间段任务，每次只查询某一个时间区间内的文档，查完再推进到下一个时间区间，避免每次查询都扫描全量时间范围的索引。

内容的提问来源于stack exchange，提问作者qwertyqwerty