后执行的update被卡住是因为innodb对匹配行加x锁，同一行不允许多事务并发修改，后到者进入锁等待；若超时则报lock wait timeout exceeded。
UPDATE WHERE条件相同，为什么后执行的会被卡住？
因为InnoDB默认对匹配行加排他锁（X锁），同一行不能被两个事务同时修改——后到的UPDATE不是报错，而是进入锁等待状态，直到前一个事务提交或回滚释放锁。
常见错误现象：Lock wait timeout exceeded、SHOW PROCESSLIST里状态长期为Updating或Waiting for lock；应用层表现为某条UPDATE响应时间从几毫秒突然飙升到几十秒。
- 阻塞不等于死锁：只要只有一个事务在改某行，其他并发请求就是安静排队，不会触发死锁检测
- 锁粒度取决于WHERE是否走索引：主键等值更新只锁单行；没索引时全表扫描，实际效果接近“伪全表锁”
-
innodb_lock_wait_timeout控制等待上限，默认50秒（生产环境常调大到120秒），超时后报错Lock wait timeout exceeded
为什么EXPLAIN显示走了索引，UPDATE还是慢且阻塞严重？
索引只是避免全表扫描，不代表锁范围就小——范围查询、间隙锁、多行匹配都会扩大锁持有面，导致后续UPDATE排队变长。
典型场景：UPDATE t SET status = 'done' WHERE created_at > '2026-07-01'，即使created_at有索引，也会加临键锁（Next-Key Lock），锁住满足条件的所有记录+间隙，别人插或改附近数据都会被拦。
- 用
SELECT * FROM INFORMATION_SCHEMA.INNODB_TRX查当前活跃事务，结合INFORMATION_SCHEMA.INNODB_LOCK_WAITS定位谁在等谁 -
SHOW ENGINE INNODB STATUS\G里的LATEST DETECTED DEADLOCK段落能直接看到锁冲突路径 - RR隔离级别下，
WHERE id BETWEEN 100 AND 200会锁住[100,200]区间所有现有行+间隙，不只是id=100和200这两行
批量UPDATE同一条件时，如何避免大面积阻塞？
别用UPDATE ... WHERE status = 'pending'一把梭——哪怕status有索引，一次性锁几千行也会把其他业务堵死。关键不是“能不能走索引”，而是“单次事务锁多少行、持有多久”。
- 必须按主键分批：先
SELECT id FROM t WHERE status = 'pending' ORDER BY id LIMIT 100，再UPDATE t SET status = 'done' WHERE id IN (1,2,3,...) - 禁止用
LIMIT 100 OFFSET 1000分页：MySQL仍可能重复扫描前面的行，锁范围不可控 - 每批执行后显式
COMMIT，并加SLEEP(0.01)缓解锁争抢和CPU压力 - 单批行数别硬套100–500：若字段含TEXT/BLOB或涉及JOIN，建议压到50–100以内
两个UPDATE语句WHERE一样，但执行计划不同，会互相阻塞吗？
会，而且容易演变成死锁——尤其当它们实际锁定的行顺序不一致时。
比如事务A执行UPDATE t SET x=1 WHERE user_id = 123 ORDER BY id，事务B执行UPDATE t SET x=2 WHERE user_id = 123（没ORDER BY），优化器可能走不同索引路径，导致加锁顺序相反：A先锁id=5再锁id=10，B先锁id=10再锁id=5 → 循环等待立刻触发死锁。
-
ORDER BY本身不保证加锁顺序，只有当它真正走索引排序（EXPLAIN里Extra不含Using filesort）才有效 - 复合索引要匹配查询谓词顺序：
(user_id, status, id)支持WHERE user_id = ? AND status = ? ORDER BY id，但WHERE status = ?就失效 - 多表UPDATE必须统一顺序：按表名字母序（
order_item → order → user）或业务流主次（order → order_item → payment），禁止动态拼接
锁的边界从来不在SQL写法表面，而在执行计划与索引结构的交界处。最危险的不是没加锁，而是你以为只锁了一行，其实锁了一片。
