MySQL 8.0中UPDATE SET x = x + 1 WHERE id = 1在200–500 QPS即卡住，根本原因是InnoDB行锁强制串行化导致线程频繁上下文切换，而非CPU或IO瓶颈；有效解法是将原子操作前移至Redis并异步批量落库，绕开单行锁争抢。
为什么UPDATE SET x = x + 1 WHERE id = 1一到200 QPS就卡住
不是MySQL“慢了”，是InnoDB行锁强制串行化：所有并发请求必须排队等待同一行的X锁。一旦QPS超过单行吞吐阈值（通常200–500），innodb_row_lock_waits飙升，线程在Updating状态长时间挂起——此时CPU使用率可能很低，但vmstat里cs（每秒上下文切换次数）会突然跳高。
根本原因在于锁等待触发频繁的线程调度：每个被阻塞的连接都由内核反复切出、唤醒、再检测锁是否释放，大量时间消耗在上下文切换而非执行SQL上。这不是IO瓶颈，也不是CPU算力不足，而是操作系统调度开销反噬了数据库吞吐。
vmstat -w和pidstat -w 2怎么看才算准
只看vmstat的cs值容易误判——它反映的是全系统级切换，MySQL只是其中一部分。真正要定位问题，得用pidstat -w 2盯住MySQL进程本身：
-
cswch（自愿切换）持续高于500/s，大概率是锁等待或I/O阻塞导致线程主动让出CPU -
nvcswch（非自愿切换）突增，说明MySQL线程被调度器强行切走，常见于事务过大、redo刷盘卡顿或锁竞争激烈 - 同时观察
r（就绪队列长度），如果长期> CPU核数，说明有大量线程在排队争抢CPU时间片
分批UPDATE却没降低cs？检查这三件事
很多人按id BETWEEN ? AND ?切片更新，但cs没降反升，问题往往不在SQL写法，而在执行环境：
MySQL8 CRM Schema Design Expert
下载
面向 CRM 系统的 MySQL 8 数据库模式设计。当用户需要为客户关系管理（CRM）系统设计、评审、优化或生成数据库模式时，应使用此项技能。
- 没确认
id字段是否有有效索引：EXPLAIN UPDATE ...输出中type必须是range，不能是ALL - 用了
autocommit=0但忘记在每批后调用COMMIT，整段逻辑仍包在一个大事务里，锁不释放、undo膨胀、上下文切换照旧 - 分片步长不合理：比如固定取10000行一批，但在高并发下仍导致单次持有锁超200ms，触发更多线程争抢和调度
别把Redis当“银弹”，先看清它在哪卸掉上下文切换
用INCR代替UPDATE SET x = x + 1确实能绕过InnoDB锁，但关键不是“快”，而是把高频原子操作从MySQL线程模型里彻底移出：
- Redis单线程处理
INCR，无上下文切换开销；MySQL连接不再为每条计数请求建事务、加锁、刷redo - 异步落库时，批量写入MySQL的节奏可由业务控制（如每5秒攒100条），大幅降低MySQL端并发压力和线程调度频率
- 风险点常被忽略：如果Redis宕机或网络抖动，
INCR成功但落库失败，会导致数据不一致——必须配套幂等写+补偿机制，而不是只换一个命令
真正的优化不是让MySQL“更快地锁同一行”，而是让绝大多数写请求根本不碰MySQL的锁路径。
