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，这时再怎么优化索引也救不了吞吐。锁不是越细越好，而是越短越好。
