区分超时类型需看报错：connection timed out属连接层问题，MaxTimeMSExpired属查询执行超时，CursorNotFound属游标空闲超时；profiling需显式启用并按数据库设置，通过db.setProfilingLevel(1,{slowms:100})记录慢操作，再查system.profile定位具体慢查询。
CRUD 超时不是单一配置能“一键修复”的问题，得先分清是连接超时、查询执行超时，还是游标空闲超时——三者触发时机、报错特征、解决路径完全不同。
怎么区分是 connectTimeoutMS 还是 maxTimeMS 超时？
报错信息是第一判断依据：
-
connection timed out或server selection timeout→ 客户端根本没连上服务端，属于连接层问题 -
MaxTimeMSExpired或ExecutionTimeout→ 请求已送达 mongod 并开始执行，但耗时超限被强制中断 -
CursorNotFound→ 游标在 10 分钟内没被续命（比如循环处理太慢），服务端已清理上下文
连接超时通常发生在应用启动或首次请求时；maxTimeMS 超时多出现在具体 find/update/aggregate 执行中；游标超时则集中在批量遍历场景。
如何用 profiling 快速定位慢 CRUD？
不开启 profiling，你永远不知道哪条 find() 卡了 2.3 秒。它必须显式启用，且每个数据库单独设：
- 连到目标库（如
myapp），执行db.setProfilingLevel(1, { slowms: 100 })：只记 >100ms 的操作 - 确认生效：
db.getProfilingStatus()返回{ "was": 1, "slowms": 100 } - 查最近 5 分钟最慢的 query：
db.system.profile.find({ op: "query", millis: { $gt: 500 } }).sort({ millis: -1 }).limit(10).project({ ns: 1, millis: 1, query: 1, planSummary: 1 })
注意：system.profile 是 capped collection，不支持索引，全表扫会极慢——务必加 millis 和 ts 过滤条件。
maxTimeMS 设置的常见错误
它不是“建议等待时间”，而是服务端硬中断点。设错会导致误判或掩盖真瓶颈：
- 在 Node.js 驱动里写成
collection.find().maxTimeMS(5000)—— 正确；写成client.connect({ maxTimeMS: 5000 })—— 无效 - PyMongo 中
aggregate()必须把maxTimeMS当作方法参数传，不能塞进coll.aggregate(pipeline, {})的空 dict 里 - mongosh 里
db.col.aggregate([], { maxTimeMS: 3000 })才生效；写成.maxTimeMS(3000)链式调用会报错 - 设了
maxTimeMS=3000却没在日志里看到对应记录？可能socketTimeoutMS=2000先触发了，请求根本没发到 mongod
游标超时最容易被忽略的场景
不是所有遍历都安全。for doc in collection.find() 看似简单，但背后是批量拉取 + 内存缓存机制：
- 默认一次 fetch 100 条，如果单条
parse_data(doc)耗时 7 秒，100 条就超 10 分钟，第 101 条 fetch 时游标已失效 - 解决办法不是调大
cursorTimeoutMillis（需重启服务，生产禁用），而是改用batchSize()控制每次网络往返量，或直接转成list(collection.find())（仅限数据量可控） - 聚合管道带
$lookup且关联集合无索引时，实际执行时间可能远超预估，maxTimeMS会被提前击穿
真正难调的从来不是参数数字，而是那些藏在 $lookup 后面的隐式全表扫描，或者事务里没加索引的 updateMany() —— 它们让所有超时设置都变成摆设。
