相同过滤排序条件下MongoDB原生find与Mongoose find命中不同索引咨询

• 字段类型不匹配：原生查询中xxxId传入的是ObjectId类型值，而示例中Mongoose查询代码直接传入了字符串类型的xxxId。如果Schema中xxxId的类型定义错误（比如误设为String而非ObjectId），或者内置类型转换逻辑异常，会导致实际发送到MongoDB服务端的查询条件中xxxId为字符串类型。MongoDB索引对数据类型敏感，字符串类型的过滤条件无法匹配针对ObjectId类型字段构建的目标索引，因此会选择其他符合类型要求的索引。
• 存在额外隐藏查询条件：Mongoose会基于Schema配置或启用的第三方插件自动附加额外查询条件，比如全局软删除逻辑附加的额外过滤字段、多租户插件自动补充的租户ID过滤条件等，肉眼可见的查询条件与实际发送到MongoDB的查询存在差异，会导致查询优化器选择不同的索引。
• 自定义查询配置干预：如果Mongoose全局、模型层面或单次查询中配置了自定义索引提示（hint）、特殊读偏好，或是针对特定字段的默认查询规则，会直接干预MongoDB的索引选择逻辑，优先走配置指定的索引而非最优匹配的目标索引。
• 查询计划缓存差异：MongoDB会按会话缓存常用查询的执行计划，如果Mongoose侧之前执行过同查询形状但参数不同的请求，缓存了非最优的执行计划，后续查询会直接复用旧计划走错误索引。而Robo 3T执行的查询属于独立会话，不会命中Mongoose会话的缓存计划，因此可以选到正确索引。
• 字段名自动转换异常：如果启用了Mongoose字段名转换插件（比如驼峰命名自动转下划线命名），可能存在代码中写的字段名和实际存储的字段名不匹配的问题，导致目标索引对应的字段没有出现在实际查询条件中，无法命中目标索引。

排查时可以执行xxxModel.find({xxxId: 'xxxx',xxxx: 'xxxxx',deleted: false}).sort({createdAt: -1}).explain()打印Mongoose实际执行的查询语句和执行计划，和原生查询的explain结果做对比，可快速定位具体差异点。

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