行锁竞争主因是锁不准、锁太久、锁不稳，90%问题可通过索引优化和事务控制解决；WHERE条件未走索引会导致全表扫描并升级为表级锁争用，需用EXPLAIN检查type字段，避免隐式转换和函数包裹索引字段。
行锁竞争不是锁太强，而是锁得不准、锁得太久、锁得不稳——90% 的问题靠索引和事务控制就能解决，不用调参数或换架构。
WHERE 条件没走索引，行锁就退化成表级竞争
哪怕你只 UPDATE 一行，只要 WHERE 条件没命中索引，InnoDB 就会全表扫描，对每行加意向锁甚至行锁。其他事务一来就排队等这把“本不该存在”的锁。
- 用
EXPLAIN看type字段：出现ALL或index必须停手优化 - 避免隐式转换：
WHERE user_id = '123'（user_id是 INT）→ 改成WHERE user_id = 123 - 别用函数包裹索引字段：
WHERE DATE(create_time) = '2026-05-01'→ 改成WHERE create_time >= '2026-05-01' AND create_time - 联合索引注意最左前缀：建了
(status, category)，但只查WHERE category = 'A'，照样全表扫
事务里混了非数据库操作，锁就一直挂着
从 BEGIN 到 COMMIT 的每一毫秒，都在持续持有锁。日志打点、发 MQ、调 HTTP 接口、甚至 file_put_contents 写文件——这些都不该出现在事务块里。
- 把通知类逻辑移出事务，用异步任务或最终一致性补偿
- 批量更新必须拆小批：
UPDATE ... WHERE id IN (1,2,...,500)，每批控制在 100–500 行 - 避免“先
SELECT再UPDATE”：改成SELECT ... FOR UPDATE WHERE id = ?一步到位，且必须带ORDER BY id ASC防死锁 - 长事务监控：查
information_schema.INNODB_TRX，重点关注trx_started和trx_state = 'RUNNING'的记录
隔离级别选错，间隙锁会锁住整个插入空隙
REPEATABLE READ 默认启用间隙锁（Gap Lock）和临键锁（Next-Key Lock），哪怕你只更新一行，也可能锁住前后几个空隙，导致新记录插入被阻塞。而 READ COMMITTED 下只加记录锁，语句执行完就释放不匹配的锁。
- 确认业务是否容忍“不可重复读”：比如订单详情页两次刷新看到不同状态，多数场景可接受
- 修改方式：
SET SESSION TRANSACTION ISOLATION LEVEL READ COMMITTED（连接级）或全局配置transaction_isolation = 'READ-COMMITTED' - 搭配
binlog_format = 'ROW'使用，避免复制异常
热点行更新卡死，得用虚拟分片打散压力
秒杀、抢券、余额扣减这类场景，单行锁天然成为瓶颈。自增主键 + 聚簇索引让物理位置固定，没法靠数据分布摊薄压力。
- 改表结构：把单行库存拆成多行，例如
goods_stock_shard (goods_id, shard_id, stock)，主键为(goods_id, shard_id) - 初始化时把总库存均分到 10 个
shard_id（0~9），扣减时用用户 ID 取模随机选槽位执行UPDATE - 查总库存用
SUM(stock) FROM goods_stock_shard WHERE goods_id = 123，允许短暂不精确 - 前置用 Redis 做原子预扣：
DECRBY尝试扣减，返回负数直接拒绝，不进 MySQL
真正难的不是写对 SQL，而是判断哪条 WHERE 条件在生产里悄悄退化成了全表扫，以及哪个看似无害的 sleep(100) 正在把整张表拖进等待队列。
