高并发更新同一行数据本身不会引发死锁，只导致锁等待或超时；死锁必须满足循环等待条件，即至少两个事务互相持有对方所需锁——单行更新仅涉及一把排他锁，无法成环。
不会。高并发更新同一行数据本身不会引发死锁，只会造成锁等待或超时（Lock wait timeout exceeded）。死锁必须满足“循环等待”条件——至少两个事务互相持有对方需要的锁。单行更新只涉及一把排他锁（X锁），不可能形成环。
为什么你看到的“同一行更新报死锁”其实是假象
表面上看是两个事务都在 UPDATE t SET x=1 WHERE id=1，但实际加锁路径不同。常见伪装场景：
- 事务A执行
UPDATE t SET a=1 WHERE id=1→ 持有主键上的记录锁 - 事务B执行
UPDATE t SET b=2 WHERE unique_col='u1'→ 该语句命中唯一索引，但InnoDB内部会先在唯一索引上加锁，再回表到主键加锁；若此时事务A尚未提交，事务B就在主键上被阻塞；而事务A后续又尝试更新unique_col='u1'（比如触发唯一约束检查或外键级联），就会反过来等事务B释放唯一索引上的锁 - 结果：A等B的唯一索引锁，B等A的主键锁 → 循环形成，死锁触发
这种“同一行”只是业务语义一致，底层锁对象实为不同索引分支。
间隙锁（Gap Lock）在单行更新中偷偷引入循环
当 WHERE 条件未命中索引，或使用了范围条件（如 WHERE amount > 100），InnoDB 会升级为临键锁（Next-Key Lock），锁住记录+间隙。这时看似更新“某一行”，实则锁了一段区间。
- 事务A：
SELECT * FROM orders WHERE order_no = 'ORD-100' FOR UPDATE（order_no无索引）→ 全表扫描，对所有扫描行加记录锁，并对末尾间隙加 Gap Lock - 事务B：
INSERT INTO orders (order_no) VALUES ('ORD-101')→ 需要获取插入意向锁（Insert Intention Lock），但被事务A的间隙锁阻塞 - 事务A接着执行另一条
INSERT INTO orders (order_no) VALUES ('ORD-101')（比如幂等重试）→ 又需要等事务B释放插入意向锁 → 死锁
根本问题不在“更新同一行”，而在“锁范围失控+操作顺序错位”。
安装、修复、更新或打包一个基于 Python 和 PyMySQL 实现的 Windows `mysql` 命令。适用于用户希望在 PowerShell/CMD 中输入 `mysql` 时重定向到 Python 实现、需要交互式输入 MySQL 连接信息、需要同步到当前用户本地 bin 目录，或需要将该能力封装成可公开复用的 Codex skill。
自增主键 + 聚簇索引让热点更危险，但不直接导致死锁
在秒杀类场景中，大量请求争抢 UPDATE stock SET num = num - 1 WHERE id = 1，确实会严重排队，但这是串行化执行，不是死锁。真正引爆死锁的是混入其他锁路径：
- 事务A：扣减库存（
id=1）→ 更新成功，但未提交 - 事务B：创建订单（含外键引用
stock.id）→ 插入前需检查外键，触发对stock表的共享锁（S锁）→ 被事务A的X锁阻塞 - 事务A后续做日志记录，写入
audit_log表，而该表有触发器去读stock当前状态 → 尝试加S锁 → 等事务B释放S锁（事务B还在等A的X锁）→ 死锁
单点热点本身安全，一旦和外键、触发器、冗余校验等耦合，就极易构建出循环依赖链。
真正容易被忽略的点是：死锁日志里显示的“冲突行”常常只是表象，背后是多个索引结构、多种锁类型、多层SQL执行阶段（查找、加锁、更新、约束检查）交织作用的结果。盯着 id=1 这个值找原因，大概率走偏。
