高频更新场景下mysql锁争用拖垮qps的核心是“少锁、快锁、散锁”，关键动作是事务瘦身、索引对齐、热点打散；update须命中主键或唯一索引，执行计划type需为const/eq_ref且rows≤1，避免函数索引失效。
高频更新场景下，MySQL锁争用直接拖垮QPS，核心不是“怎么加锁”，而是“怎么少锁、快锁、散锁”。关键动作就三类：事务瘦身、索引对齐、热点打散。
UPDATE语句是否命中主键或唯一索引
没走索引的UPDATE会扫全表或整个索引范围，锁住成百上千行，QPS瞬间腰斩。这不是慢查询，是锁风暴。
- 用
EXPLAIN检查UPDATE执行计划：type必须是const或eq_ref，rows≤ 1；若出现ALL或index，立刻补索引 - WHERE条件别写
WHERE DATE(created_at) = '2026-06-01'——函数导致索引失效，改用WHERE created_at >= '2026-06-01' AND created_at - 联合索引字段顺序要匹配查询条件，
WHERE status = ? AND category = ?需建(status, category)索引，而非反过来
事务里有没有HTTP调用、日志写入或SLEEP
事务从BEGIN到COMMIT期间，所有锁都不释放。哪怕只在中间SLEEP(100)，其他想改同一行的请求就全卡住——连接池满、超时报错、P99延迟飙升。
- 把所有非DB操作移出事务块：RPC调用、本地文件写、格式化JSON、甚至
printf日志都得挪到COMMIT之后 - 批量更新必须分页，例如
UPDATE t SET state=2 WHERE id BETWEEN ? AND ?，单次控制在100–500行，避免单次锁太久 - 别用“查-改-更”模式：
SELECT FOR UPDATE后做业务逻辑再UPDATE，锁持有时间不可控；优先改用UPDATE ... WHERE id = ? AND version = ?原子更新
热点行是否做了分段（shard）处理
单行UPDATE如UPDATE stock SET qty = qty - 1 WHERE product_id = 123，所有请求挤在同一行X锁上，本质是单点瓶颈。分段不是可选项，是必选项。
- 建表加
shard_id字段，主键设为(product_id, shard_id)；初始化按shard_id均分库存，如1000件分10槽，每槽100件 - 扣减时随机选槽：
shard_id = product_id % 10或FLOOR(RAND() * 10)，然后UPDATE stock SET qty = qty - 1 WHERE product_id = 123 AND shard_id = 7 - 必须满足三个前提：WHERE条件命中联合主键（
EXPLAIN确认key为PRIMARY）、事务仅含单条UPDATE、隔离级别为READ COMMITTED
分段能压降80%+行锁竞争，但真正扛住流量的从来不是MySQL单点——Redis预扣、队列限速、前端防重，这些才是第一道防线。锁优化不是调参，是把数据库从“业务执行器”还原成“数据持久层”。
