MySQL 8.0通过拆分lock_sys为分片哈希表、独立管理各分区锁等待队列、优化死锁检测及拆解trx_sys->mutex，显著降低锁争用，使多核CPU真正并行处理事务。
MySQL 8.0锁系统重构如何释放多核CPU潜力
MySQL 8.0对InnoDB锁系统的重构，核心不是“加锁更快”，而是大幅减少了线程间争抢同一把锁的频率——尤其是lock_sys全局锁和trx_sys->mutex事务系统互斥量。这直接让多个CPU核心能真正并行处理不同事务的加锁/解锁操作，而不是排队等一个锁。
为什么旧版InnoDB在多核下容易“假瓶颈”
在MySQL 5.7及之前，大量并发事务尝试获取行锁时，会频繁竞争lock_sys->mutex这把全局互斥锁。哪怕事务操作的是完全不重叠的行，也得串行进入锁系统做插入、查找、唤醒等待队列等动作。CPU监控常显示单核100%、其余核空闲，本质是锁争用导致的线程阻塞，而非计算瓶颈。
- 典型现象：
SHOW ENGINE INNODB STATUS中LOCK WAIT数量高，但ROW OPERATIONS里实际冲突行极少 - perf top能看到大量时间花在
ib_mutex_enter或os_event_wait上 - sysbench oltp_read_write压测时，
threads=64的QPS可能还低于threads=32
InnoDB 8.0锁系统做了哪些关键拆分
MySQL 8.0将原来高度集中的锁管理逻辑拆分为更细粒度、局部化的组件，降低共享资源争用：
-
lock_sys从单个全局结构改为分片哈希表（sharded hash table），默认按hash(key)分散到多个独立锁分区，每个分区有自己的mutex - 行锁等待队列不再统一维护，改为每个锁分区独立管理其下的
lock_wait_list，唤醒逻辑也局部化 - 死锁检测从全局扫描改为只检查当前锁分区内的等待图，配合跨分区异步探测机制
-
trx_sys->mutex被进一步拆解，事务提交路径中与锁无关的操作（如redo写入）不再受其阻塞
配置与验证要点
锁分片数由innodb_lock_schedule_algorithm隐式影响，但更直接可控的是innodb_sync_array_size（决定锁分区数量，默认16，最大支持1024）。调大它能进一步摊薄争用，但需注意内存开销和哈希冲突概率上升：
- 生产环境建议先从默认16起步，若
SHOW STATUS LIKE 'Innodb_mutex_spin_waits'持续高于10⁶/s，再逐步调至32或64 - 避免盲目设为1024：每个分区需额外约8KB内存，且低并发下反而增加哈希计算开销
- 验证效果不能只看QPS，重点观察
Threads_running峰值是否更平稳、Innodb_row_lock_time_avg是否显著下降
真正起作用的从来不是参数本身，而是锁热点是否被有效打散——如果业务集中在某几个主键范围（比如订单号连续递增），即使分片再多，也会打到同一分区，此时得靠业务层打散ID或改用UUID/雪花ID。
