MySQL热点行更新卡住是因为高并发下InnoDB行锁排队所有事务争抢同一record lock导致串行化表现为Lock wait timeout、Threads_running突增但QPS低、慢日志中UPDATE耗时超100ms。MySQL热点行更新为什么会卡住因为 InnoDB 的行锁在高并发下会排队而 UPDATE 语句如果反复修改同一行比如计数器、库存字段所有事务都在等同一个 record lock实际变成串行执行。这时候 CPU 可能不高但 innodb_row_lock_waits 和 innodb_row_lock_time_avg 会明显升高。常见错误现象Lock wait timeout exceeded监控里看到 Threads_running 突增但 QPS 上不去慢日志里大量 UPDATE ... WHERE id ? 耗时集中在 100ms。别用 SELECT ... FOR UPDATE 应用层计算再 UPDATE这延长了锁持有时间避免在事务里做 HTTP 请求、文件读写等外部依赖锁住热点行的同时还干别的事等于主动拖长队列确认是否真需要实时精确值——很多场景其实可以接受“最终一致”比如浏览量、点赞数用 INSERT ... ON DUPLICATE KEY UPDATE 合并写请求这是最轻量的合并方案把多次小更新攒成一次靠唯一键触发“插入或更新”逻辑绕过显式加锁流程。适用于有自增主键 唯一键如 user_id的计数表。使用场景用户行为埋点汇总如 click_count、轻量级库存预占配合后续校验。示例表结构CREATE TABLE user_counter ( user_id BIGINT PRIMARY KEY, click_count INT DEFAULT 0, updated_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP);批量合并写法应用层聚合后一次性提交 Stylized AI产品图背景替换