MySQL行锁“失效”实为锁粒度放大，主因是无索引导致全表扫描并升级为间隙锁/临键锁；需确保WHERE字段有有效索引、合理选用隔离级别与锁机制，并严格控制事务时长。
MySQL 的行锁在高并发下为什么经常“失效”
不是锁本身失效，而是事务隔离级别、索引缺失或锁类型误用导致锁粒度意外放大。比如 UPDATE user SET status = 1 WHERE name = 'alice'，若 name 字段没有索引，InnoDB 会退化为全表扫描 + 行锁升级为间隙锁（Gap Lock）甚至临键锁（Next-Key Lock），最终阻塞大量无关行。
- 务必确认 WHERE 条件字段有有效索引，
EXPLAIN输出中type至少为ref或更优 - 避免在事务中执行无索引的
SELECT ... FOR UPDATE，它可能锁住整个聚簇索引范围 - READ COMMITTED 隔离级别下间隙锁被禁用，可减少锁冲突，但需确认业务能否接受不可重复读
如何识别正在阻塞的锁和源头 SQL
靠 SHOW ENGINE INNODB STATUS\G 太难读，优先用系统视图定位。MySQL 5.7+ 提供了 performance_schema 中的锁视图，比旧方式直观得多。
- 查当前被阻塞的事务：
SELECT * FROM performance_schema.data_lock_waits;
- 查持有锁的线程及对应 SQL：
SELECT t.PROCESSLIST_ID, t.PROCESSLIST_INFO, l.OBJECT_NAME, l.INDEX_NAME, l.LOCK_TYPE, l.LOCK_MODE FROM performance_schema.data_locks l JOIN performance_schema.threads t ON l.THREAD_ID = t.THREAD_ID WHERE l.LOCK_TRX_ID IN (SELECT BLOCKING_TRX_ID FROM performance_schema.data_lock_waits);
- 注意：需提前开启相关消费者：
UPDATE performance_schema.setup_consumers SET ENABLED = 'YES' WHERE NAME LIKE 'global_instrumentation';
乐观锁 vs 悲观锁：什么时候该用 version 字段而不是 SELECT ... FOR UPDATE
在库存扣减、积分变更等“读多写少+冲突概率低”的场景，SELECT ... FOR UPDATE 会过早加锁，抬高等待成本；而基于 version 字段的乐观更新（UPDATE t SET balance = ?, version = ? WHERE id = ? AND version = ?）把锁检查推迟到写入瞬间，吞吐更高。
- 乐观锁失败后必须重试逻辑，不能只抛异常——否则请求直接 500，高并发下雪崩风险大
- 悲观锁适合“写密集+强一致性要求”场景，如金融类账户余额实时划转，且必须搭配短事务（
FOR UPDATE后立刻UPDATE+COMMIT） - 注意：乐观锁的
WHERE条件里version必须是单列且有索引，否则可能触发全表扫描
批量更新时锁竞争爆炸的典型陷阱
UPDATE orders SET status = 'shipped' WHERE user_id IN (1001, 1002, ..., 10000) 看似简单，但在高并发下极易引发锁等待风暴——InnoDB 对每个匹配行逐个加锁，且顺序依赖索引 B+ 树遍历路径，不同事务加锁顺序稍有差异就死锁。
- 拆成小批量（如每次 100 行），用
WHERE id BETWEEN ? AND ?替代IN列表，保证加锁顺序一致 - 避免在批量语句中混用非主键条件，例如
WHERE create_time > '2024-01-01' AND status = 'pending'—— 若无联合索引，很可能走全表扫描加锁 - 考虑用
INSERT ... ON DUPLICATE KEY UPDATE替代先查后更，减少事务内查询环节，缩短锁持有时间
实际调优中最容易被忽略的，是事务边界和锁生命周期的错配：一个本该 20ms 完成的更新，因为前面加了日志记录、远程调用或慢查询，让锁持有了 500ms，这时再怎么优化索引也救不了吞吐。锁不是越细越好，而是越短越好。
