行锁冲突严重，本质是多个事务反复争抢同一行或相邻行的锁资源，靠调参或加索引往往治标不治本。真正有效的解法是主动减少“争抢动作”本身——把高并发下的热点更新打散，把零散请求聚合成可控批次。
为什么UPDATE同一行会卡住整个业务链
InnoDB 的行锁不是“锁住某个值”，而是锁住索引记录（包括主键、唯一索引、甚至间隙）。当多个事务同时执行类似 UPDATE users SET balance = balance + 10 WHERE id = 123 时，哪怕只是读-改-写一个字段，也会因持有 X 锁直到事务结束，导致后续请求排队等待。
等待超时由 innodb_lock_wait_timeout 控制，默认 50 秒，但业务通常等不了几秒若该行还被其他事务用 SELECT … FOR UPDATE 长期持有，冲突会更隐蔽即使有主键索引，只要并发量上去，id = 123 就成了事实上的“单点瓶颈”
拆分热点更新：用「状态暂存 + 异步聚合」绕过行锁
适用于账户余额、库存计数、点赞数等典型热点场景。核心思路是：不直接改原表字段，而是先记日志，再异步合并。
建一张轻量级变更表，如 user_balance_delta，字段含 user_id、delta、created_at业务层把 UPDATE users SET balance = balance + 10 替换为 INSERT INTO user_balance_delta (user_id, delta) VALUES (123, 10) —— 这条语句几乎不锁原表，且可批量插入用定时任务或消息队列消费 user_balance_delta，按 user_id 分组 sum(delta)，再一次性更新 users.balance注意：读取余额时需查 users.balance + COALESCE((SELECT SUM(delta) FROM user_balance_delta WHERE user_id = 123 AND processed = 0), 0)
合并请求：在应用层做「写合并」而非数据库层硬扛
前端或网关层收到大量相似更新（如“用户 A 点赞文章 B”），不要每条都发一条 SQL，而应聚合后再下发。
使用 Redis 的 INCRBY 或 LPUSH + BRPOPLPUSH 做请求缓冲，比如每 100ms 或积满 50 条就 flush 一次合并后生成去重后的 ID 列表，用 INSERT … ON DUPLICATE KEY UPDATE 或 REPLACE INTO 批量落地避免在合并逻辑里做复杂校验（如余额是否足够），这类强一致性检查仍需回到数据库，但已大幅降低频率警惕合并引入的延迟：对实时性要求高的场景（如支付扣款），不能合并；但对点赞、浏览统计类完全适用
容易被忽略的关键点
很多人试了拆分和合并，却发现效果有限——问题常出在两个地方：一是没清理“隐式锁竞争”，比如 UPDATE 语句没走索引，实际锁了一堆行；二是没控制好事务边界，把日志写入和后续查询包在一个事务里，又造出新锁点。真正压测时，要盯住 SHOW ENGINE INNODB STATUS 里的 TRANSACTIONS 和 LATEST DETECTED DEADLOCK 段，确认锁等待是否从“某一行”变成了“某几张日志表”，这才是拆分生效的信号。
评论(0)