MongoDB跨分片事务不触发显式死锁错误，而是表现为长时间Waiting for lock或WT_ROLLBACK中断；db.currentOp()可识别超30秒且waitingForLock为true的可疑事务，结合ns字段判断是否涉及多分片键集合。
db.currentOp() 查看阻塞中的事务操作
跨分片死锁在 MongoDB 中不会触发显式错误，而是表现为事务长时间卡在 Waiting for lock 状态，或直接被 WT_ROLLBACK 中断。此时最直接的线索来自 db.currentOp() ——它能暴露正在等待锁、且已运行数十秒以上的操作。
执行以下命令过滤出可疑长事务：
db.currentOp({
"secs_running": { "$gt": 30 },
"waitingForLock": true,
"ns": { "$regex": "^your_db\." }
})
重点关注返回结果中的：
-
opid和secs_running：确认是否真有超时事务 -
ns字段值：检查是否涉及多个分片键不同的集合（如orders和users），这是跨分片事务被拒绝的前置信号 -
msg或killPending：若已有killPending: true，说明系统已尝试清理但未成功
db.serverStatus().locks 检查锁等待统计异常
分片集群中，真正引发死锁风险的不是全局锁，而是各分片上独立积累的写锁等待。单看主路由节点的 serverStatus 不够，必须连到每个分片的 mongod 实例分别执行：
db.serverStatus().locks.Global.acquireWaitCount.w
如果某一分片的 w（写锁等待次数）持续增长，而 timeAcquiringMicros.w 同步飙升，说明该分片正成为瓶颈。特别注意：
- 分片间数值差异过大（比如 shard0 是 shard1 的 5 倍以上），往往意味着业务流量倾斜 + 分片键设计不合理
-
deadlockCount字段非零，代表 WiredTiger 已检测到内部锁冲突（虽不等于跨分片死锁，但属于高危信号） - Atlas 集群可能不返回完整
locks字段，需改用 Atlas Metrics UI 查看Mongod Lock Acquire Wait Time指标
事务启动失败时的 IllegalOperation 错误含义
当应用报错 IllegalOperation: Cannot perform transaction with operations on multiple shards，这不是死锁，而是事务根本没开始——MongoDB 在 session.startTransaction() 阶段就拒绝了跨分片操作。
这通常由以下原因导致：
- 参与事务的集合未使用相同分片键（例如
orders按user_id分片，payments却按payment_id分片） - 集合是未分片的（
shardCollection未执行），却和已分片集合混用在同一事务中 - 查询中用了不支持的模式，如对不同分片键字段做
$lookup聚合后再更新（即使目标集合物理同片，优化器也可能误判）
修复方式不是“绕过限制”，而是重构数据模型：把强关联实体（如订单、支付、物流单）强制落到同一分片键下，例如统一用 order_id 作为所有相关集合的分片键前缀。
日志中定位跨分片协调失败的关键线索
MongoDB 不会在日志里写“deadlock detected”，但会在分片路由节点（mongos）日志中留下事务协调失败痕迹。搜索以下关键词：
-
aborting transaction due to timeout：事务超时被transactionLifetimeLimitSeconds（默认 60 秒）强制终止 -
could not find transaction coordinator：协调节点不可达，常见于网络分区或 config server 故障 -
stale config detected：分片元数据过期，导致mongos将请求发错分片，进而引发锁竞争错位
这些日志往往出现在 /var/log/mongodb/mongos.log，而非 mongod.log。如果日志量大，建议用 grep -A 5 -B 5 "transaction" 提取上下文，重点看时间戳是否集中爆发。
跨分片场景下，死锁本质是协调失序而非资源争抢。最容易被忽略的是：事务生命周期内分片键值发生变更（比如更新了 user_id），会导致后续操作被路由到错误分片，锁状态彻底失控。这种问题不会立刻报错，但会让监控指标缓慢恶化。
