不能。nocursortimeout=true 仅防游标空闲超时，不防会话 30 分钟过期；单批处理超时仍报 cursornotfound；batch_size() 通过分批重置计时器更稳妥。
noCursorTimeout=True 真的能彻底防超时吗？
不能。设置 noCursorTimeout=True 只是告诉 MongoDB“别因空闲 10 分钟就 kill 我的游标”，但它 ** 不豁免会话超时 **——而会话默认 30 分钟就过期，过期即连带关闭所有关联游标。哪怕你设了 noCursorTimeout=True，只要处理单批数据耗时超过 30 分钟（比如解析巨型文档、调外部 API、写慢盘），游标照样被服务器静默终止，报错 CursorNotFound。
常见错误现象：pymongo.errors.CursorNotFound: cursor id 123456789 not found，尤其在长循环中调用 parse_data() 类耗时函数时高频出现。
- 适用场景：适合单次处理快、但总迭代时间可能超 10 分钟的中等数据量遍历（比如每条处理
- 不适用场景：单条处理 >30 秒；或需稳定运行数小时的离线清洗任务
- 注意：MongoDB Atlas 的 M0/Flex 集群直接不支持
noCursorTimeout命令，设了也无效
batch_size() 是比 noCursorTimeout 更稳的选择
batch_size() 不是“防止超时”，而是“把超时风险切碎”——它强制让游标每次只返回指定数量文档（如 5000 条），客户端取完这批后，驱动会自动发新请求拉下一批，相当于重置游标空闲计时器。只要单批处理时间
实操建议：
- 从
batch_size(1000)起手，观察单批平均耗时；若远低于 60 秒，可逐步加大到5000或10000 - 务必搭配
noCursorTimeout=True使用（两者不冲突，是协同关系） - 避免设过大（如
batch_size(100000)）：可能 OOM，且单批处理一旦卡住，仍会超时 - Python 示例：
collection.find({}, no_cursor_timeout=True).batch_size(5000)
大任务必须管住会话生命周期
当你要跑几小时的数据迁移，光靠 noCursorTimeout 和 batch_size 还不够——30 分钟会话超时仍是隐形炸弹。正确做法是显式创建会话，并定期刷新。
关键点：
- 用
MongoClient.start_session()创建会话，再把查询绑定进去 - 每 25 分钟左右调一次
client.admin.command("refreshSessions", [session.session_id])（注意：不是refreshSessions命令本身，而是通过admin.command发送） - 会话 ID 可从
session.session_id获取，别硬编码 - 别忘了异常时手动
session.end_session()，否则会话残留占用资源
别碰 cursorTimeoutMillis 全局配置
有人搜到 db.adminCommand({setParameter: 1, cursorTimeoutMillis: 300000}) 想延长全局游标超时——这方案在生产环境基本等于自找麻烦。
原因很实在：
- 需要重启 mongod 或执行命令生效，Atlas 上根本不可行
- 改的是所有游标，包括临时聚合、后台索引构建等，可能拖垮其他业务
- 治标不治本：会话超时（30 分钟）依然存在，改了游标超时也没用
- 本地开发调试可以试试，上线前务必 revert
真正该调的，从来不是服务器参数，而是你的查询方式和会话管理逻辑。游标超时不是 bug，是 MongoDB 防止资源泄漏的设计，绕开它不如顺应它。
