MongoDB错误码400对应的游标未找到是服务端驱动在迭代游标时最常遇到的异常之一。从数据库的视角看，这个错误并不是说某条数据不存在，而是客户端持有的游标在服务端已经被销毁，后续的getMore请求无法继续推进。理解这一机制不仅能快速定位问题，也有助于设计更健壮的数据遍历方案。
认识游标生命周期：为什么游标会凭空消失
MongoDB的查询结果通常通过游标返回。客户端执行find命令时，服务端不是一次性返回所有数据，而是保存在一个内部游标中，客户端每次通过getMore命令获取一批数据。游标的生命周期受到服务端内存、会话超时、客户端处理速度等多重因素影响。
默认情况下，MongoDB会为游标设置10分钟的空闲超时。如果客户端在10分钟内没有发起新的getMore请求，服务端会自动回收该游标。当客户端继续请求下一批数据时，服务端已经找不到游标，于是返回错误码400，提示游标未找到。这里的超时属于空闲超时，不是游标从创建到结束的总时长，所以即使一个游标已经存在了很久，只要每隔几分钟就发起一次getMore，它依然可以保持有效。
除了空闲超时，服务端重启、内存压力较大时对闲置游标的清理、分片集群路由变化、以及客户端驱动版本与服务端版本不兼容，也都可能导致游标状态失效。在分片集群上，游标由mongos节点持有，如果mongos发生重启或主从切换，客户端的游标对象也会随之变成无效状态。因此排查问题时不能只盯住应用代码，还要关注数据库运维层面的变更。
排查游标未找到的常见场景
在开发环境中，最容易触发问题的是在循环中处理大量数据的过程。例如用Python跑一个全量数据导出任务，每读一批数据后执行耗时的外部API调用，此时两次getMore之间的时间可能超过10分钟，游标就被服务端清理。下一次迭代时驱动继续调用getMore，服务端返回错误码400，整个任务异常终止。
另一种典型场景是batchSize设置不合理。如果batchSize设置得过大，客户端拉取到一批数据后需要很长时间才能消费完，而在这段时间内客户端不会发起新的getMore请求，服务端同样会因为空闲超时回收游标。很多人误以为只要还在处理数据，游标就不会失效，但从服务端的角度看，只要没有网络请求，就属于空闲状态。因此处理速度慢且批次数据量大的任务，更容易出现游标未找到的错误。
在分片集群上，游标未找到可能表现得更加随机。客户端每次getMore请求会被路由到不同的mongos节点，如果某个mongos节点异常重启，它上面保存的游标就会丢失。此时错误可能间歇性出现，而且难以通过复现测试稳定还原。遇到这种情况，需要同时查看mongos日志和应用日志，确认是否有节点重启或迁移事件与报错时间点重合。
从代码层面解决错误码400
最直接的解决方案是允许游标不因空闲超时被清理。在MongoDB中可以通过设置noCursorTimeout标志来延长游标的生命周期，但使用这个选项时必须手动关闭游标，否则会造成服务端资源泄漏。例如在Python中使用pymongo，可以这样设置：
from pymongo import MongoClient
client = MongoClient("mongodb://localhost:27017")
db = client.test_db
collection = db.users
# no_cursor_timeout=True 表示游标不因空闲超时自动关闭
cursor = collection.find({}).no_cursor_timeout(True)
try:
for doc in cursor:
# 处理每条数据
process(doc)
finally:
cursor.close()
需要注意的是，即使设置了noCursorTimeout，服务端仍然可能因为异常情况回收游标，所以还是要对游标未找到异常做捕获处理。从资源管理角度出发，不建议对所有查询都开启noCursorTimeout，而应该只针对确实需要长时间遍历的批量任务开启，并在finally块中确保游标被关闭。
除了设置超时，还可以调整批次大小，让游标保持活跃。通过batch_size参数控制每次getMore返回的数据量，避免单次处理时间过长。比如将默认的101个文档调低到50，或者调高到1000，需要根据实际处理速度来评估。如果单条数据处理需要几百毫秒，那么批次越小越好，这样客户端可以更频繁地发起getMore请求，相当于持续告诉服务端游标仍然在使用中。
# 使用 batch_size 控制游标活跃度
cursor = collection.find({}).batch_size(200)
for doc in cursor:
# 单批次数据量小，处理速度更快，游标不容易超时
process(doc)
另一个更稳妥的思路是完全避免长游标，使用基于排序键的分页查询。每次查询固定数量的记录，以查询结果中的最后一个字段值作为下一次查询的起点。这种方式不受游标生命周期限制，适合大批量导出场景。下面是一个基于_id的简单分页示例：
last_id = None
page_size = 1000
while True:
query = {}
sort_condition = [("_id", 1)]
if last_id:
query["_id"] = {"$gt": last_id}
docs = list(collection.find(query).sort(sort_condition).limit(page_size))
if not docs:
break
for doc in docs:
process(doc)
last_id = docs[-1]["_id"]
这个方案利用索引和条件查询，避免了游标长期持有，是生产环境中最推荐的遍历方式之一。需要注意，分页查询必须依赖稳定的排序键，否则可能出现数据重复或丢失。如果业务上没有合适的排序键，可以额外创建一个单调递增的字段，例如时间戳加随机数，或者直接使用ObjectId的递增特性。
构建稳健的异常处理与监控机制
即使在代码中设置了noCursorTimeout，也不能完全迷信它。服务端可能因为内存压力主动清理空闲时间较长的游标，网络分区也会导致客户端与服务端之间的游标状态无法同步。因此必须为游标操作增加异常捕获与重试逻辑。
以Python为例，可以捕获pymongo.errors.CursorNotFound异常，然后重新执行查询。不过重试前需要评估操作是否是幂等的，避免重复处理数据。如果游标已经迭代了一部分数据，重试时需要过滤掉已经处理过的记录，或者将整个任务设计成可重复执行的形式。
from pymongo.errors import CursorNotFound
for attempt in range(3):
try:
cursor = collection.find({}).no_cursor_timeout(True)
for doc in cursor:
process(doc)
break
except CursorNotFound:
print("游标已失效，准备重试")
continue
在运维层面，还需要关注MongoDB日志中的游标回收信息，并监控客户端每次getMore的间隔时间。如果发现频繁出现游标未找到错误，可以从应用代码和数据量两个维度同时优化。比如将数据分割成多个小的任务队列，每个任务使用独立游标，这样即使某个游标失效，也不会影响全部数据的处理。
最后，游标未找到的故障不应该只当作偶发错误处理，而应该从数据访问模式出发，设计适合自己业务的遍历方案。理解游标机制是第一步，合理使用noCursorTimeout、batchSize和分页技巧才能彻底根治。在真实的项目中，把异常处理、监控和重试机制结合起来，才能让数据遍历任务真正稳定可靠。
mongodb游标未找到error_code_400mongodb游标超时修改时间：2026-08-17 17:38:48