MySQL并发更新同一行时，为何性能突变？CPU切换分析揭示真相。

本文共计676个文字，预计阅读时间需要3分钟。

MySQL变慢了，不是慢在数据库本身，而是InnoDB行锁强制串行化：

根本原因在于锁等待触发频繁的线程调度：每个被阻塞的连接都由内核反复切出、唤醒、再检测锁是否释放，大量时间消耗在上下文切换而非执行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写法，而在执行环境：

• 没确认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的锁路径。