MongoDB find_one_and_update生产环境为何不使用索引？

根据你的描述，生产环境中操作触发COLLSCAN但Robo3T手动执行正常，这里有几个最可能的原因和对应的排查/解决步骤：

1. 查询计划缓存“记住”了糟糕的执行计划 #

MongoDB的查询优化器会缓存执行计划，一旦某个查询的计划被缓存为COLLSCAN，后续相同的查询会复用这个计划——哪怕最优计划是IXSCAN。这种情况常发生在索引刚创建不久、或者第一次执行查询时索引还未就绪的场景。

解决方法：
清除该集合的查询计划缓存，然后重新执行操作：

// 在MongoDB shell中执行
db.your_collection.getPlanCache().clear()

之后再运行你的Python代码，观察是否切换为IXSCAN。

2. 代码中存在参数类型不匹配 #

虽然你在样例中用了正确的ObjectId，但生产环境中可能存在参数转换错误：比如_id被当作字符串而非ObjectId传递给查询条件。如果数据库中的_id是ObjectId类型，而查询条件里传的是字符串，那么_id的匹配条件永远不成立，MongoDB会退而扫描全表寻找data.status="new"的文档（但最终找不到匹配_id的记录）。

排查方法：
在代码中打印出最终生成的filter对象，确认_id的类型是bson.ObjectId而非字符串：

from bson import ObjectId
import datetime

filter_query = {
    "$and": [
        {"data.status": "new"},
        {"_id": ObjectId("5f41983da09c453f96cebf02")},
    ]
}
print(type(filter_query["$and"][1]["_id"]))  # 正常应该输出 <class 'bson.objectid.ObjectId'>

3. 查询优化器错误评估了条件选择性 #

你的查询同时包含_id（唯一索引）和data.status（单键索引），理论上MongoDB应该优先选择_id索引（因为它能直接定位到单个文档）。但在某些极端数据分布下（比如data.status="new"的文档占比极高），查询优化器可能错误地认为全表扫描更快。

验证与解决方法：
在生产环境中对该查询执行explain("executionStats")，查看查询优化器的决策细节：

explain_result = collection.find_one_and_update(
    filter=filter_query,
    update=update_query
).explain("executionStats")
print(explain_result["queryPlanner"]["winningPlan"])
print(explain_result["queryPlanner"]["rejectedPlans"])

如果rejectedPlans里包含IXSCAN的计划，说明查询优化器知道有索引可用，但选择了COLLSCAN。此时可以用索引提示强制MongoDB使用_id索引：

from pymongo import ASCENDING

document = collection.find_one_and_update(
    filter=filter_query,
    update=update_query,
    hint=[("_id", ASCENDING)]  # 强制使用_id索引
)

4. 索引状态异常 #

虽然你提到已经创建了索引，但生产环境中可能存在索引未完全构建、被禁用或损坏的情况。

排查方法：
执行getIndexes()确认索引存在且状态正常：

// 在MongoDB shell中执行
db.your_collection.getIndexes()

检查输出中是否包含data.status和_id的索引，且v字段为当前版本（比如2或3），没有hidden或disabled等异常属性。如果索引是刚创建的，可以用db.your_collection.currentOp()查看是否有正在进行的索引构建任务。

5. 多余的$and语法可能干扰优化（可能性较低） #

MongoDB默认会将多个查询条件视为逻辑与，显式的$and虽然语法正确，但在极少数情况下可能影响查询优化器的解析。可以尝试简化filter条件，去掉$and：

filter_query = {
    "data.status": "new",
    "_id": ObjectId("5f41983da09c453f96cebf02")
}

然后重新测试执行计划。

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