目录
前言
MySQL锁
意向锁 - Intention Locks
索引记录锁 - Record Locks
间隙锁 - Gap Locks
临键锁 - Next-Key Locks
插入意向锁 - Insert Intention Locks
AUTO-INC Locks
死锁
死锁产生条件
InnoDB对死锁的检测
前言
在高并发场景下数据库性能往往是尤为重要的，通常会采用一些缓存中间件来解决数据库并发问题。这篇文章将介绍数据库层面一些与并发有关的知识。
MySQL锁
1）锁类型
锁类型依赖于存储引擎，在InnoDB存储引擎中按照锁的粒度分为，行级锁 RECORD ，和表级锁TABLE
行级锁：是对表中的某些具体的数据行进行加锁
表级锁：是对整个数据表进行加锁
2）锁模式
锁模式，⽤来描述如何请求(申请)锁，分为共享锁(S)、独占锁(X)、意向共享锁(IS)、意向独占锁(IX)、记录锁（精准行锁）、间隙锁、Next-Key锁（临键锁）、AUTO-INC锁、空间索引的谓词锁等。
共享锁和排他锁 - Shared and Exclusive Locks
InnoDB实现了标准的行级锁，分为两种分别是共享锁(S锁)和独占锁(X锁)，独占锁也称为排他锁。
共享锁(S锁)：允许持有该锁的事务读取表中的一行记录，同时允许其他事务在锁定行上加另⼀个共享锁并读取被锁定的对象，但不能对其进行写操作，也就是加排他锁需要阻塞等待。
独占锁(X锁)：允许持有该锁的事务对数据行进行更新或删除，同时不论其他事务对锁定行进行读取或修改都不允许对锁定行进行加锁，也就是加共享锁和排他锁都会阻塞。
示例：
- 如果事务T1持有R行上的共享锁(S)，那么事务T2请求R行上的锁时会有如下处理:
- T2请求S锁会立即被授予，此时T1和T2都对R行持有S锁
- T2请求X锁不能立即被授予，阻塞到T1释放持有的锁
- 如果事务T1持有R行上的独占锁(X)，那么T2请求R行上的任意类型锁都不能立即被授予，事务T2必须等待事务T1释放R行上的锁
读锁是共享锁的一种实现，写锁是排他锁的一种实现
意向锁 - Intention Locks
InnoDB支持多粒度锁，允许行锁和表锁共存
- InnoDB使⽤意向锁实现多粒度级别的锁，意向锁是表级别的锁，它并不是真正意义上的加锁，而只是在 data_locks 中记录事务以后要对表中的哪一行加哪种类型的锁(共享锁或排他锁)，意向锁分为两种:
- 意向共享锁(IS)：表示事务打算对表中的单个行设置共享锁。
- 意向排他锁(IX)：表示事务打算对表中的单个行设置排他锁。
- 在获取意向锁时有如下协议：
- 在事务获得表中某一行的共享锁(S)之前，它必须⾸先获得该表上的IS锁或更强的锁。
- 在事务获得表中某一行的排他锁(X)之前，它必须⾸先获得该表上的IX锁。
- 意向锁可以提⾼加锁的性能，在真正加锁之前不需要遍历表中的行是否加锁，只需要查看⼀下表中的意向锁即可
- 在请求锁的过程中，如果将要请求的锁与现有锁兼容，则将锁授予请求的事务，如果与现有锁冲突，则不会授予；事务将阻塞等待，直到冲突的锁被释放
- 除了全表锁定请求之外，意向锁不会阻⽌任何锁请求；意向锁的主要⽬的是表示事务正在锁定某行或者正在意图锁定某行
索引记录锁 - Record Locks
索引记录锁称为精准行锁，顾名思意是指索引记录上的锁，如下SQL锁住的是指定的一行
# 在MySQL8中使用for update进行加排他锁
select * from user where id = 1 for update;索引记录锁总是锁定索引行，在表没有定义索引的情况下，InnoDB创建一个隐藏的聚集索引，并使用该索引进行记录锁定，当使用索引进行查找时，锁定的只是满足条件的行。
间隙锁 - Gap Locks
间隙锁锁定的是索引记录之间的间隙，或者第一个索引记录之前，再或者最后一个索引记录之后的间隙。如图所示位置，根据不同的查询条件都可能会加间隙锁。
例如有如下SQL，锁定的是ID (10, 20)之间的间隙，注意不包括10和20的行，目的是防止其他事务将ID值为15的列插入到列 user 表中(无论是否已经存在要插入的数据列)，因为指定范围值之间的间隙被锁定了。
select * from user where id between 10 and 20 for update- 间隙可以跨越单个或多个索引值
- 对于使⽤唯一索引查询到的唯一行，不使用间隙锁，如下语句，id列有唯一的索引，只对id值为100的行使用索引记录锁：
-
select * from user where id = 1;
-
- 如果id没有被索引，或者是一个非唯一的索引，以上语句将锁定对应记录前面的间隙
- 不同事务的间隙锁可以共存，一个事务的间隙锁不会阻止另一个事务在相同的间隙上使用间隙锁；共享间隙锁和独占间隙锁之间没有区别
- 当事务隔离级别设置为 READ COMMITTED 时间隙锁会被禁用，对于搜索和索引扫描不再使用间隙锁定
临键锁 - Next-Key Locks
Next-Key锁是索引记录锁和间隙锁的组合。它使用索引记录锁锁定具体行，再使用间隙锁锁住该行前面的间隙，等于就是一开一闭的区间。
- InnoDB搜索或扫描⼀个表的索引时，执行行级锁策略，具体方式是：在扫描过程中遇到的索引记录上设置共享锁或排他锁，因此，行级锁策略实际上应用的是索引记录锁。索引记录上的 next-key 锁也会影响该索引记录之前的"间隙"，也就是说， next-key 锁是索引记录锁加上索引记录前面的间隙锁。如果一个会话对索引中的一条记录R具有共享锁或排他锁，则另一个会话不能在索引记录R之前的空白中插⼊新的索引记录行
- 假设索引包含值10、11、13和20，这些索引可能的 next-key 锁覆盖以下区间，其中圆括号表示不包含区间端点，方括号表示包含端点:
- （负无穷，10 ]，（10，11 ]，（11，13 ]，（13， 20 ]，（20，正无穷 ]
- 默认情况下， REPEATABLE READ 事务隔离级别开启 next-key 锁并进行搜索和索引扫描，可以防止幻象行，从而解决幻读问题
插入意向锁 - Insert Intention Locks
插⼊意向锁是⼀个特殊的间隙锁，在向索引记录之前的间隙进行insert操作插⼊数据时使用，如果多个事务向相同索引间隙中不同位置插入记录，则不需要彼此等待。假设已经存在值为10和20的索引记录，两个事务分别尝试插入索引值为15和16的行，在获得插入行上的排他锁之前，每个事务都⽤插⼊意向锁锁住10到20之间的间隙，但不会相互阻塞，因为他们所操作的行并不冲突。
插入意向锁只是标记某个事务要对某行进行插入数据，不同事务之间获取插入意向锁不会产生锁竞争。
示例：
事务A要对事务B使用排他锁锁定的区间进行插入数据，事务A首先会标记插入意向锁，然后获取排他锁阻塞等待，直到事务B事务结束释放排他锁，这个时候事务A就可获取到锁，进行插入数据。
AUTO-INC Locks
AUTO-INC锁也叫自增锁是一个表级锁，服务于配置了 AUTO_INCREMENT 自增列的表。在插入数据时会在表上加自增锁，并生成自增值，同时阻塞其他的事务操作，以保证值的唯一性。需要注意的是，当一个事务执行新增操作已生成自增值，但是事务回滚了，申请到的主键值不会回退，这意味着在表中会出现自增值不连续的情况。
死锁
由于每个事务都持有另一个事务所需的锁，导致事务无法继续进行的情况称为死锁。以下图为例，两个事务都不会主动释放自己持有的锁，并且都在等待对方持有的资源变得可用。
死锁产生条件
1）互斥访问：如果线程1获取到了锁A，那么线程2就不能同时得到锁A
2）不可抢占：获取到锁的线程，只能自己主动释放锁，别的线程不能从他的手中抢占锁
3）保持与请求：线程1已经获得了锁A，还要在这个基础上再去获了锁B
4）循环等待：线程1等待线程2释放锁，线程2也等待线程1释放锁，死锁发⽣时系统中⼀定有由两个或两个以上的线程组成的⼀条环路，该环路中的每个线程都在等待着下一个进程释放锁
以上四条是造成死锁的必要条件，必须同时满足，所以如果想要打破死锁，可以破坏以上四个条件之一，最常见的方式就是打破循环等待。
InnoDB对死锁的检测
1）InnoDB在运行时会对死锁进行检测，当死锁检测启用时(默认)，InnoDB自动检测事务死锁，并回滚一个或多个事务来打破死锁。InnoDB尝试选择小事务进行回滚，其中事务的大小由插入、更新或删除的行数决定。
2）如果系统变量 innodb_table_locks = 1 (默认) 和 autocommit = 0 ，InnoDB可以检测到表级锁和行级锁级别发生的死锁；否则，无法检测到由 lock TABLES 语句设置的表锁或由非InnoDB存储引擎设置的锁，对于无法检测到的死锁，可以通过设置系统变量innodb_lock_wait_timeout 的值来指定锁的超时时间来解决死锁问题。
3）当超过 200 个事务等待锁资源或等待的锁个数超过 1,000,000 个时也会被视为死锁，并尝试将等待列表的事务回滚。
4）在高并发系统中，多个线程等待相同的锁时，死锁检测可能会导致性能降性变慢，此时禁用死锁检测并依赖 innodb_lock_wait_timeout 设置进行事务回滚可能性能更高。可以通过设置系统变量 innodb_deadlock_detect[={OFF|ON}] 禁用死锁检测。
以下为常用查看MySQL死锁信息命令
# 查看当前服务器发生死锁次数
SELECT `count` FROM INFORMATION_SCHEMA.INNODB_METRICS WHERE NAME="lock_deadlocks";
# 查询死锁和事务相关信息；查看 LATEST DETECTED DEADLOCK 节点的内容
SHOW ENGINE INNODB STATUS
# 查询错误日志路径
SELECT @@log_error;
# 查看锁信息
SELECT ENGINE_TRANSACTION_ID as Trx_Id, OBJECT_NAME as `Table`, INDEX_NAME as `Index`, LOCK_DATA as Data,LOCK_MODE as Mode, LOCK_STATUS as Status, LOCK_TYPE as TypeFROM performance_schema.data_locks;
# 查看锁等待信息
SELECT REQUESTING_ENGINE_LOCK_ID as Req_Lock_Id, REQUESTING_ENGINE_TRANSACTION_ID as Req_Trx_Id, BLOCKING_ENGINE_LOCK_ID as Blk_Lock_Id, BLOCKING_ENGINE_TRANSACTION_ID as Blk_Trx_IdFROM performance_schema.data_lock_waits
# 查看锁信息
SELECT ENGINE_LOCK_ID as Lock_Id, ENGINE_TRANSACTION_ID as Trx_id, OBJECT_NAME as `Table`, INDEX_NAME as `Index`, LOCK_DATA as Data,LOCK_MODE as Mode, LOCK_STATUS as Status, LOCK_TYPE as Type FROM performance_schema.data_locks;
