死锁概率不能用“并发数×系数”估算，因其本质是事务加锁顺序构成环路的逻辑状态，而非资源争抢的统计结果；哪怕仅2个并发事务，若更新顺序相反（如A先id=5后id=3、B反之），即刻触发死锁。
没有固定数学公式，死锁概率不随并发数线性或幂律增长；它取决于事务访问模式是否形成循环等待，而非单纯数量叠加。
为什么不能用“并发数 × 某系数”估算死锁概率
死锁不是资源争抢的统计结果，而是多个事务在加锁顺序上恰好构成环路的逻辑状态。哪怕单机只有 2 个并发事务，只要一个先更新 id=5 再更新 id=3，另一个反向操作，就立即触发死锁。反过来，100 个并发事务若全部按 id 升序更新同一张表，InnoDB 甚至可能全程不产生一次死锁。
关键点在于：
win可用的mysql指令skill
下载
安装、修复、更新或打包一个基于 Python 和 PyMySQL 实现的 Windows `mysql` 命令。适用于用户希望在 PowerShell/CMD 中输入 `mysql` 时重定向到 Python 实现、需要交互式输入 MySQL 连接信息、需要同步到当前用户本地 bin 目录，或需要将该能力封装成可公开复用的 Codex skill。
- 并发数只是提供“形成环路”的机会窗口，不是驱动力量
- 真正决定是否死锁的是事务内 SQL 的索引路径、WHERE 条件覆盖范围、执行顺序这三者组合
- InnoDB 的死锁检测是离散事件（wait-for graph 中出现环），不是连续函数可建模
哪些参数/行为会让死锁概率随并发上升而明显升高
当以下条件同时存在时，死锁频率会显著抬升，但仍是非线性跃变，而非平滑增长：
- 多个事务频繁更新相同热点行（如账户余额、库存计数器），且无统一锁序
- SQL 使用不同索引访问同一行（例如事务 A 用
WHERE id=123，事务 B 用WHERE username='xxx'），导致锁落在主键和二级索引两个结构上 - 批量更新未加索引字段（如
UPDATE t SET status=1 WHERE category='A'），触发隐式锁升级或间隙锁扩散 - 事务中混入慢操作（如调用外部 HTTP、长循环计算），拉长锁持有时间，放大交叉等待窗口
线上可观测的实用判断依据
比起建模预测，更应关注以下信号：
-
SHOW ENGINE INNODB STATUS输出中LATEST DETECTED DEADLOCK区块的出现频次 —— 若每秒超过 1 次，说明访问模式已出问题 - Performance Schema 中
events_waits_summary_global_by_event_name表里wait/synch/mutex/innodb/lock_mutex等等待事件突增，往往 precede 死锁爆发 - 应用层捕获到大量
Deadlock found when trying to get lock; try restarting transaction，且重试后仍高频失败，说明根本原因未解
真正危险的不是“并发高”，而是“多个事务对同一组行以任意顺序加锁”。只要锁序不可控，哪怕并发从 10 增到 20，死锁率也可能从 0 跳到 5%；而一旦强制统一为 ORDER BY id ASC 或使用 SELECT ... FOR UPDATE ORDER BY id 预锁，即使并发冲到 200，死锁也可能归零。
