UPDATE同一行仍会死锁，因InnoDB行锁为排他锁，多事务并发争抢同一主键行锁、锁序不一致或存在前序锁时易形成环路；需通过SHOW ENGINE INNODB STATUS和INNODB_TRX定位热点行，并采用队列削峰、乐观锁重试、逻辑拆分、异步写入等策略规避。
为什么UPDATE同一行还会死锁
很多人以为“只更新一行”就不可能死锁，其实不然。InnoDB的行锁是排他锁（X锁），所有并发事务对同一主键行执行UPDATE时，都会尝试获取该行的X锁——但锁不是瞬间拿到的。当多个事务几乎同时发起UPDATE t SET x = x + 1 WHERE id = 123，且其中某些事务还夹杂了其他操作（比如先SELECT ... FOR UPDATE查别的行、或带子查询、或触发触发器），就可能因锁获取顺序/等待链形成环路。更隐蔽的是：即使语句完全一样，若事务中混入了未提交的前序锁（如之前锁过id=456），而另一个事务反向锁了456→123，照样死锁。
检查是否真由热点行引发——别被表象骗
先确认是不是“真热点”，而不是误判。执行SHOW ENGINE INNODB STATUS\G，重点看LATEST DETECTED DEADLOCK段里锁住的record lock是否反复指向同一个PRIMARY值（如space id 123 page no 567 n bits 80后紧跟着id=123）。同时查information_schema.INNODB_TRX，观察TRX_STATE = 'LOCK WAIT'的事务是否长时间卡在相同TRX_MYSQL_THREAD_ID对应的UPDATE上。如果发现大量事务都堵在WHERE id = ?且?恒为某几个值，基本可断定是热点行问题。
绕开行锁竞争的四种实操路径
不硬扛锁，而是改变数据访问模式：
- 用应用层队列削峰：把对同一
id的更新请求收拢到单个Worker线程串行处理，避免数据库层争抢；适合库存扣减、积分累加等幂等场景 - 改用原子操作+重试：
UPDATE t SET counter = counter + 1 WHERE id = 123 AND version = 12配合乐观锁version字段，失败则读新version重试；避免持有锁等待 - 拆分热点为逻辑多行：比如原
user_id=123的总余额，拆成shard_id IN (0,1,2,3)四条记录，更新时WHERE user_id = 123 AND shard_id = CRC32('123') % 4，最后聚合查询；分散物理行压力 - 异步化写入：将更新转为写消息队列（如Kafka），由消费者单线程落库；牺牲毫秒级一致性，换高吞吐和零死锁
索引与隔离级别必须同步调优
死锁常是组合问题。即使只更新一行，若WHERE条件没走主键（比如写了WHERE name = 'xxx'且name无索引），InnoDB会升级为全表扫描+表级意向锁，放大冲突面。务必确保所有高频UPDATE都命中主键或唯一索引。另外，把隔离级别从默认的REPEATABLE READ降到READ COMMITTED，能禁用间隙锁（Gap Lock），减少因范围查询意外锁住相邻行导致的连锁等待——但要注意这会弱化幻读防护，需业务侧兜底。
最易被忽略的一点：死锁日志里显示的“最后一行SQL”往往不是根因，而是压垮骆驼的最后一根稻草。真正要盯的是每个事务开头的SELECT ... FOR UPDATE或第一个UPDATE，它们锁住的资源顺序决定了整个死锁链。所以优化永远要从事务最开始那条加锁语句下手，而不是只盯着报错那行。
