在事务机制中，锁机制是为了保证高并发，数据一致性的重要实现方式。MySQL除了Innodb引擎层面的行锁，还有latch锁。latch锁的作用资源协调处理。包含表句柄，线程，cpu线程，内存池等。其保证非常短时间内快速处理的同时，通过wait，loop方式进行队列，实现资源协调。期间这些资源被互斥锁“保护”，不存在死锁机制，通过队列机制处理。

比如：两个线程，两个用户会话同时执行一个查询，需要访问相同的资源(一个文件、一个缓冲区或一些数据)时，这两个线程相互竞争。因此，第一个获取互斥锁的查询会导致另一个查询等待，直到第一个查询完成并解锁互斥锁。MySQL持有互斥锁时执行的工作被称为“critical section临界区”，虽然数据库本身的处理机制里实现了并行方式，但底层资源确实以序列化方式(一次一个)执行这个临界区， 这是一个潜在的瓶颈。

临界资源的使用的信号量（mutex互斥量），就是为了不同线程占有的资源，在硬件资源（cpu，内存，io，网络）里有效的使用的方式。

MySQL 8.0版本对mutex进行了拆分，其实现3种mutex锁， 2种策略的实现方式：

这两种策略（GenericPolicy，BlockMutexPolicy）主要的区别在于在show engine innodb mutex 的时候不同的统计方式.

承载量

8.0.21版本开始互斥锁(lock_sys->互斥锁)被以下分片锁取代:

一个全局锁存器(lock_sys->latch .global_latch)，由64个读写锁对象(rw_lock_t)组成。访问单个锁队列需要共享全局锁闩和锁队列的锁闩。需要访问所有锁队列的操作使用一个独占的全局锁存器，该锁存器锁存所有表和页锁队列碎片。

Table shard latch (lock_sys->latch .table_shards.mutexes)，实现为一个512互斥锁的数组，每个互斥锁专用于512个表锁队列。512*512=262144表数量

Page shard latch (lock_sys->latch .page_shards.mutexes)，实现为一个由512个互斥锁组成的数组，每个互斥锁专用于512个Page lock queue。512*512=262144页，比如一个页100行数据 26214400行，每次也就操作2600w行。

mysql > SHOW ENGINE INNODB MUTEX;

在performance_schema也输出mutex相关信息：

通过指标 可检测包含互斥的线程之间的瓶颈：

mysql > SHOW CREATE TABLE performance_schema.mutex_instances;

CREATE TABLE `mutex_instances` (

`NAME` varchar(128) NOT NULL,

`OBJECT_INSTANCE_BEGIN` bigint(20) unsigned NOT NULL,

`LOCKED_BY_THREAD_ID` bigint(20) unsigned DEFAULT NULL

) ENGINE=PERFORMANCE_SCHEMA DEFAULT CHARSET=utf8

在setup_instruments里wait/synch/mutex/ 统计mutex相关信息。InnoDB互斥锁等待 有85种。ommit，buf_pool_LRU，dict_table_mutex 等：

多核系统中，多个线程调用系统层面的同一个共享对象，目前基本实现方式是轮询机制。过多频繁的调动，可能会导致“cache ping pong”现象。当处理跟不上的时候，就会堵塞，穷住等情况。InnoDB通过强制轮询之间的随机延迟（spin-wait loop机制）来减少这个问题，从而去同步轮询活动。

2种类型：

MySQL数据库中的mutex是一个需要考虑硬件协调性实现，其中要考虑多种资源的平衡因素的关键性机制。 在实际环境中哪里会知道 不同的操作系统的互斥层和innodb层互斥，该设置多少合理。所以一般维持默认值。