必须重构访问模式以避免多事务更新同一行：用skip locked分流读取+分配类场景；对热点行采用状态暂存+异步聚合；批量写合并降低并发量；严格控制事务边界。
直接结论：别让多个事务同时更新同一行——这不是调参能解决的问题，而是必须重构访问模式。 MySQL 8.0 的行锁机制没变，innodb_row_lock_waits 持续升高说明你已经卡在热点行上；关掉 innodb_deadlock_detect 或调大 innodb_lock_wait_timeout 只会让问题更隐蔽，不会减少竞争本身。
用 SELECT ... FOR UPDATE SKIP LOCKED 避开争抢，但仅限读取+分配类场景
它不适用于“所有事务都要改 id=123 这一行”的情况，而是帮你把“争抢”变成“分流”。典型适用场景是任务队列分发、库存预占、分页取数等。
- 错误写法：
SELECT * FROM tasks WHERE status = 'pending' ORDER BY id LIMIT 1 FOR UPDATE—— 所有并发线程都卡在第一条 pending 记录上，触发密集死锁检测 - 正确写法：
SELECT id, status FROM tasks WHERE status = 'pending' ORDER BY id LIMIT 1 FOR UPDATE SKIP LOCKED—— 每个线程跳过已被锁定的行，拿到一个**未被锁的可用行**，彼此无交集、无等待、无检测开销 - 注意：
SKIP LOCKED在UPDATE ... WHERE ... IN (SELECT ...)子查询中会报错ER_NOT_SUPPORTED_YET，也不能用于UPDATE语句本身（只支持SELECT ... FOR UPDATE）
对真正无法拆分的热点行（如用户余额、计数器），用「状态暂存 + 异步聚合」绕过行锁
这不是妥协，而是把数据库从“高频率同步更新引擎”降级为“最终一致性落库通道”。关键在于让写入路径几乎不触碰原表主键行。
- 业务层把
UPDATE users SET balance = balance + 10 WHERE id = 123替换为INSERT INTO user_balance_delta (user_id, delta) VALUES (123, 10)—— 这条语句走自增主键，基本不锁原表，且可批量插入 - 异步消费者按
user_id分组汇总SUM(delta)，再执行一次UPDATE users SET balance = balance + ? WHERE id = ? - 读取时需合并：查
users.balance+ 未处理的user_balance_delta累加值，用COALESCE((SELECT SUM(delta) FROM user_balance_delta WHERE user_id = 123 AND processed = 0), 0) - 容易忽略：若没清理已处理的
delta记录，会导致重复累加；务必在异步更新成功后原子标记processed = 1或删掉记录
批量写合并 + 应用层缓冲，把 N 次更新压成 1 次
适合点赞、浏览统计、日志埋点等弱一致性要求场景。目标是让数据库看到的并发请求数量下降一个数量级。
- 在网关或服务入口用 Redis
LPUSH缓存待更新 ID，每 100ms 或积满 50 条触发一次BRPOPLPUSH拉取并消费 - 去重、分组后生成批量语句，例如：
INSERT INTO article_stats (article_id, view_count) VALUES (1,1),(2,1) ON DUPLICATE KEY UPDATE view_count = view_count + VALUES(view_count) - 不要在缓冲层做余额校验、库存扣减等强一致性逻辑——这些仍需回 DB，但频次已大幅降低
- 风险点：合并引入延迟，支付、订单创建等实时性敏感操作绝不能走这条路
最常被忽略的其实是事务边界：很多“热点行更新”问题，根源不是 SQL 写得不好，而是把 HTTP 调用、RPC、文件 IO 塞进了事务里，导致锁持有时间从毫秒拉长到秒级。检查你的 BEGIN 和 COMMIT 之间有没有非 DB 操作——有，就先移出去。
