直接killOp无法终止事务写操作，因其仅终止mongos上的读操作，而写操作需通过killSessions命令终止关联会话；prepared状态事务则需等待超时或手动提交/中止。
直接 killOp 无法终止事务中的写操作
db.killOp() 在分片集群上对写操作基本无效——它只在 mongos 上终止读操作，而写操作（如 update、insert）即使关联了会话，也不会被 killOp 传播到分片节点。你看到 opid 并执行 db.killOp(<opid>) 后事务仍在运行，这是预期行为，不是命令没生效。
真正能中断事务执行的，是终止其底层会话。但要注意：killAllSessions 不处理“准备中（prepared）”状态的事务，这类跨分片事务已由协调器发出 prepare 请求，只能等超时或手动 commit/abort。
- 先查活跃会话：用
db.adminCommand({$listSessions: {allUsers: true}})或db.aggregate([{$currentOp: {allUsers: true}}]) - 关注字段
state：值为"inProgress"的才可被终止；"prepared"的跳过 - 确认会话是否属于目标事务：检查
txnNumber和lsid是否匹配你的应用 session ID
安全终止事务会话要用 killSessions 而非 killAllSessions
killAllSessions 风险太高——它会无差别干掉所有用户会话，包括监控、备份、复制心跳等后台任务。生产环境应避免使用空数组调用 db.runCommand({killAllSessions: []})。
正确做法是定位到具体会话 ID，调用 killSessions 命令：
db.adminCommand({
killSessions: [
{id: UUID("a1b2c3d4-e5f6-7890-g1h2-i3j4k5l6m7n8"), uid: BinData(0, "...")}
]
})
其中 UUID 来自 $listSessions 返回的 id 字段，uid 是可选但推荐带上，用于权限校验。
- 必须有
killAnySession权限，否则只能杀自己的会话 - 命令需在 admin 数据库下执行，不能在业务库中调用
- 终止后，该会话内所有未确认写入将回滚，已写入但未提交的数据会被清理
事务卡住时优先检查锁和索引热点
很多所谓“异常事务”其实卡在 WiredTiger 行锁或文档级锁上，比如一个慢查询长时间持有读锁，导致后续事务反复 WriteConflict（错误码 112）并重试，看起来像卡死。
先运行 db.currentOp({secs_running: {$gt: 5}}) 查看运行超 5 秒的操作，重点关注：
-
secs_running大但ns是小集合 → 可能缺少索引，正在全表扫描 -
waitingForLock: true→ 明确存在锁等待，找出持锁者（看secs_running更长的那个） -
type: "idleTransaction"且secs_running持续增长 → 客户端未主动结束事务，可能是网络断连或代码未调用session.endSession()
此时与其强行 kill，不如优化查询：给 updateOne 条件字段加索引，或把大事务拆成多个带 maxTimeMS 的小事务。
事务超时控制必须靠 maxTimeMS + 应用层兜底
MongoDB 本身不提供事务级超时，maxTimeMS 只作用于单个操作（如 find、updateOne），不能限制整个 withTransaction 块的总耗时。
所以必须在应用侧实现双重防护：
- 每个事务内操作显式加
.maxTimeMS(3000)，防止单步卡死 - 外层用
Promise.race包裹整个事务逻辑，例如：Promise.race([transactionPromise, new Promise(r => setTimeout(() => r(new Error('tx timeout')), 10000))]) - 捕获
MaxTimeMSExpired错误后，主动调用session.abortTransaction()，再释放 session
注意：驱动不会自动 abort 超时事务，不手动调用就可能留下 idleTransaction 占着会话和锁。
事务真正难处理的点不在“怎么杀”，而在“杀完之后状态是否一致”。WiredTiger 的 prepared 状态事务、未响应的客户端、以及 killSessions 后残留的游标，都可能让数据处于中间态。线上操作前，务必确认副本集多数节点可写，且没有正在进行的初始同步（initial sync）。
