MongoDB 写入报 LockTimeout 通常意味着写操作在等待锁时超过了限制，常见于长查询占用资源或锁竞争激烈的场景。排查时优先使用 db.currentOp() 查看活跃操作，避免直接重启实例以免触发数据文件修复。
先说结论：LockTimeout 报错本质是资源争用导致写操作无法及时获取锁，需优先定位阻塞源而非调整超时参数。
- 先确认：通过 db.currentOp() 识别持有锁的长耗时操作。
- 先处理：终止异常查询或优化索引以减少锁持有时间。
- 再验证：观察慢查询日志和服务器状态确认锁等待消失。
命令速用版
以下命令需在 mongo shell 或兼容客户端中执行，用于快速抓取锁等待现场。
db.currentOp({"secs_running": {"$gte": 1}})：查看运行超过 1 秒的活跃操作。
db.serverStatus().locks：查看当前锁统计信息（WiredTiger 引擎下参考 global 或 database 锁）。
db.currentOp({"waitingForLock": true})：直接筛选正在等待锁的操作。
为什么会这样
MongoDB 写入锁等待超时主要由长事务或未索引查询占用资源引起。WiredTiger 引擎虽支持文档级锁，但元数据操作或特定冲突仍会触发全局或库级锁竞争。
当写操作请求锁时，若前序读操作或写操作未释放资源，后续请求会进入等待队列。一旦等待时间超过客户端驱动或服务端配置的阈值（如 maxTimeMS），即报 LockTimeout 或类似超时错误。公开资料中没有看到可靠的量化数据说明具体多少并发会触发，这取决于硬件 IO 和数据分布。
分步处理
步骤 1：定位阻塞操作
执行 db.currentOp({"waitingForLock": true})。若返回结果不为空，记录 opid 和 query 字段。
步骤 2：评估是否终止
确认阻塞操作是否为必要业务。若是异常长查询，执行 db.killOp(<opid>)。风险边界：终止操作可能导致客户端报错，需确保应用层有重试机制。
步骤 3：优化索引与查询
对阻塞查询涉及的集合执行 explain()。若发现 COLLSCAN（全表扫描），需补充索引。避免在热点文档上高频更新。
步骤 4：调整写入策略
检查写入 concern 配置。若设置为 majority 且副本集延迟高，会增加锁持有时间。非关键数据可临时调整为 1。
怎么验证是否生效
再次执行 db.currentOp({"waitingForLock": true})，返回结果应为空或数量显著减少。检查 MongoDB 日志文件（通常位于 /var/log/mongodb/mongod.log），确认不再出现 timeout 相关报错。
常见坑
1. 盲目 kill 操作：终止系统内部任务可能导致实例不稳定，仅终止用户查询。
2. 忽略磁盘 IO：锁等待有时是磁盘写入瓶颈的表象，需同时监控 iostat。
3. 误判引擎差异：MMAPv1 引擎锁竞争更严重，若仍在使用建议升级 WiredTiger。
常见问题
LockTimeout 和 WriteConflict 有什么区别？
LockTimeout 通常指等待锁超时，WriteConflict 是 WiredTiger 特有的写冲突重试失败。两者都指向并发竞争，但后者更常见于高并发写入场景。
可以直接调大超时时间解决吗？
不建议。调大超时时间仅掩盖问题，可能导致积压更多请求。应优先优化查询效率。
副本集主节点锁等待高怎么办？
检查从节点同步延迟。若从节点应用日志慢，可能拖累主节点确认速度，需优化从节点硬件或网络。
参考来源
1. MongoDB Manual, "db.currentOp()", https://www.mongodb.com/docs/manual/reference/method/db.currentOp/
2. MongoDB Manual, "WiredTiger Concurrency", https://www.mongodb.com/docs/manual/core/wiredtiger/#concurrency