UPDATE语句卡住或超时的根本原因是并发修改同一行时锁等待，而非SQL性能问题；行级锁仅在事务中且WHERE命中索引时生效，全表扫描会升级为表锁或加锁失败。
UPDATE 语句为什么突然卡住或超时
因为默认没加锁，多个事务同时改同一行时，后到的会等前一个事务释放锁——但如果你没显式开启事务或没设隔离级别，可能连“等”都看不到，直接报 Lock wait timeout exceeded。
根本原因不是 SQL 写得慢，而是没控制并发修改的粒度。行级锁只在事务中生效，且仅对 WHERE 条件命中索引的行起作用；全表扫描更新会升级为表锁，或者被优化器拒绝加锁。
- 确保
WHERE字段有索引，否则SELECT ... FOR UPDATE或UPDATE ... WHERE可能锁不住具体行，甚至锁整张表 - 用
EXPLAIN看执行计划，确认type是const、ref或range，不是ALL - 避免在事务里做 HTTP 请求、文件读写等长耗时操作，锁持有时间越长，并发冲突概率越高
SELECT ... FOR UPDATE 不生效的常见情况
它只在事务内、可重复读（REPEATABLE READ）或串行化（SERIALIZABLE）隔离级别下才真正加行锁；读已提交（READ COMMITTED）下只能防止脏读，不保证后续 UPDATE 不冲突。
更隐蔽的问题是：如果 SELECT 的 WHERE 条件和后续 UPDATE 不一致，比如 SELECT 用 id = ? 加锁，UPDATE 却用 status = ? AND id = ?，而 status 字段没索引，MySQL 可能无法复用之前的锁，导致幻读或重复更新。
- 必须用
BEGIN/START TRANSACTION显式开启事务，不能依赖自动提交模式 - 确保 SELECT 和 UPDATE 的 WHERE 条件完全匹配，且都走相同索引路径
- 注意
SELECT ... FOR UPDATE在唯一索引 + 等值查询时锁单行，范围查询（如id > 100）会锁间隙（Gap Lock），影响插入
UPDATE ... WHERE 比 SELECT + UPDATE 更安全吗
不一定。单纯靠 UPDATE ... WHERE version = ? 这类乐观锁能防覆盖，但不防并发修改引发的业务逻辑错乱——比如扣库存，两个事务都读到剩余 10，各自减 1 后写回 9，实际应剩 8。
悲观锁（SELECT ... FOR UPDATE）才是真正在数据库层阻塞并发写，但代价是锁等待和死锁风险。关键看场景：金融类强一致性操作必须用，计数类或幂等更新可以接受乐观重试。
- 高并发秒杀场景，优先用
SELECT ... FOR UPDATE+ 显式事务，配合唯一索引 WHERE - 状态流转类更新（如订单从 pending → paid），建议 WHERE 中包含当前状态，例如
UPDATE orders SET status = 'paid' WHERE id = ? AND status = 'pending'，失败即说明已被改过 - 避免在应用层做“先查再判再更”的三步操作，中间任何一步失败都会让锁失效或逻辑断裂
死锁日志里看到 “WAITING FOR THIS LOCK TO BE GRANTED” 怎么办
这不是错误，是正常现象；真正要处理的是 MySQL 主动回滚某个事务并报 Deadlock found when trying to get lock。死锁常发生在两个事务以不同顺序访问相同资源，比如事务 A 先锁行 X 再锁行 Y，事务 B 反过来先锁 Y 再锁 X。
排查重点不是“怎么避免锁”，而是“怎么让加锁顺序一致”。应用层最容易控制的就是 WHERE 条件的排序逻辑——强制按主键升序取数据，就能大幅降低死锁概率。
- 用
SHOW ENGINE INNODB STATUS\G查最近死锁详情，重点关注TRANSACTION块里的 SQL 和LOCK WAIT链路 - 批量更新时，对 ID 列
ORDER BY id ASC再遍历，确保所有事务按相同物理顺序加锁 - 把大事务拆小，比如一次更新 1000 行，分 10 次每次 100 行，减少锁持有时间和范围
行级锁不是银弹，它把问题从“数据错乱”转移到“响应延迟”和“死锁重试”。真正难的不是加锁语法，是判断哪条业务路径必须串行，哪条可以妥协为最终一致。
