MySql 事务 锁

一、事务概述

1.1 基本概念

事务：一组逻辑操作单元，使数据从一种状态变换到另一种状态。
事务处理的原则：保证所有事务都作为 一个工作单元 来执行，即使出现了故障，都不能改变这种执行方式。当在一个事务中执行多个操作时，要么所有的事务都被提交(commit)，那么这些修改就 永久地保存下来；要么数据库管理系统将 放弃 所作的所有 修改 ，整个事务回滚( rollback )到最初状态。

1.2 事务的ACID特性

1.2.1 原子性 atomicity

原子性是指事务是一个不可分割的工作单位，要么全部提交，要么全部失败回滚。即要么转账成功，要么转账失败，是不存在中间的状态。如果无法保证原子性会怎么样？就会出现数据不一致的情形，A账户减去100元，而B账户增加100元操作失败，系统将无故丢失100元。

1.2.2 一致性 consistency

定义：一致性是指事务执行前后，数据从一个 合法性状态 （满足预定的约束的状态）变换到另外一个 合法性状态 。 这种状态是 语义上 的而不是语法上的，跟具体的业务有关。
这状态是由你自己来定义的(比如满足现实世界中的约束)。满足这个状态，数据就是一致的，不满足这个状态，数据就是不一致的！如果事务中的某个操作失败了，系统就会自动撤销当前正在执行的事务，返回到事务操作之前的状态。

1.2.3 隔离性 isolation

事务的隔离性是指一个事务的执行 不能被其他事务干扰 ，即一个事务内部的操作及使用的数据对 并发 的其他事务是隔离的，并发执行的各个事务之间不能互相干扰。

1.2.4 持久性 durability

持久性是指一个事务一旦被提交，它对数据库中数据的改变就是 永久性的，接下来的其他操作和数据库故障不应该对其有任何影响。
持久性是通过 事务日志 来保证的。日志包括了 重做日志和 回滚日志。当我们通过事务对数据进行修改的时候，首先会将数据库的变化信息记录到重做日志中，然后再对数据库中对应的行进行修改。这样做的好处是，即使数据库系统崩溃，数据库重启后也能找到没有更新到数据库系统中的重做日志，重新执行，从而使事务具有持久性。

1.3 四种隔离级别

• READ UNCOMMITTED：读未提交，在该隔离级别，所有事务都可以看到其他未提交事务的执行结果。不能避免脏读、不可重复读、幻读。
• READ COMMITTED：读已提交，它满足了隔离的简单定义：一个事务只能看见已经提交事务所做的改变。这是大多数数据库系统的默认隔离级别(但不是MySQL默认的)。可以避免脏读，但不可重复读、幻读问题仍然存在。
• REPEATABLE READ：可重复读，事务A在读到一条数据之后，此时事务B对该数据进行了修改并提交，那么事务A再读该数据，读到的还是原来的内容。可以避免脏读、不可重复读，但幻读问题仍然存在。这是MvSOL的默认隔离级别。
• SERIALIZABLE：可串行化，确保事务可以从一个表中读取相同的行。在这个事务持续期间，禁止其他事务
  对该表执行插入、更新和删除操作。所有的并发问题都可以避免，但性能十分低下。能避免脏读、不可重复读和幻读。
  

1.4 事务日志

redo log：是存储引擎层(innodb)生成的日志，记录的是 物理级别 上的页修改操作，比如页号xxx、偏移量yy写入了zzz数据。主要为了保证数据的可靠性;
undo log：是存储引擎层(innodb)生成的日志，记录的是 逻辑操作 日志，比如对某一行数据进行了INSERT语句操作，那么 undo log就记录一条与之相反的DELETE操作。主要用于 事务的回滚(undo log 记录的是每个修改操作的 逆操作)和 一致性非锁定读 (undo log 回滚行记录到某种特定的版本.–MVCC，即多版本并发控制)。

二、锁

2.1 表锁 Table Lock

该锁会锁定整张表，它是 MySOL 中最基本的锁策略，并 不依赖于存储引擎 (不管你是 MySQL 的什么存储引擎对于表锁的策略都是一样的)，并且表锁是开销最小的策略(因为粒度比较大)。由于表级锁一次会将整个表锁定，所以可以很好的 避免死锁 问题。当然，锁的粒度大所带来最大的负面影响就是出现锁资源争用的概率也会最高，导致 并发率大打折扣。

2.1.1 表级别的S锁、X锁

在对某个表执行SELECT、INSERT、DELETE、UPDATE语句时，InnoDB存储引擎是不会为这个表添加表级别的 S锁或者 X锁 的。在对某个表执行一些诸如 ALTER TABLE、 DROP TABLE这类的 DDL语句时，其他事务对这个表并发执行诸如SELECT、INSERT、DELETE、UPDATE的语句会发生阻塞。同理，某个事务中对某个表执行SELECT、INSERT、DELETE、UPDATE语句时，在其他会话中对这个表执行 DDL 语句也会发生阳寨。这个过程其实是通过在server层使用一种称之为元数据锁(英文名: Metadata Locks，简称MDL)结构来实现的。
一般情况下，不会使用InnoDB存储引擎提供的表级别的 S锁 和 X锁 。只会在一些特殊情况下，比方说 崩溃恢复 过程中用到。比如，在系统变量autocommit=8，innodb_table_locks=1时，手动获取InnoDB存储引擎提供的表t 的 S锁 或者 X锁 可以这么写：

• LOCK TABLES t READ：InnoDB存储引擎会对表t加表级别的S锁
• LOCK TABLES t WRITE：InnoDB存储引擎会对表t加表级别的X锁

lock tables mylock write;
lock tables mylock read;
#释放锁
unlock tables;

2.1.2 意向锁 （intention lock）

InnoDB 支持 多粒度锁(multiple granularity locking)，它允许 行级锁与表级锁 共存，而意向锁就是其中的一种表锁 。

1. 意向锁的存在是为了协调行锁和表锁的关系，支持多粒度(表锁与行锁)的锁并存。
2. 意向锁是一种 不与行级锁冲突表级锁 。
3. 表明某个事务正在某些行持有了锁或该事务准备去持有锁

意向锁分为两种：

• 意向共享锁(intention shared lock,ls)：事务有意向对表中的某些行加共享锁(S锁)

--事务要获取某些行的S锁，必须先获得表的 IS 锁。
SELECT COlumn FROM table ... LOCK IN SHARE MODE;

• 意向排他锁(intention exclusive lock,IX)：事务有意向对表中的某些行加排他锁(X锁)

--事务要获取某些行的X锁，必须先获得表的IX锁。
SELECT column FROM table ... FOR UPDATE;

即：意向锁是由存储引擎 自己维护的，用户无法手动操作意向锁，在为数据行加共享/排他锁之前，inooDB 会先获取该数据行 所在数据表的对应意向锁。

意向锁要解决的问题
现在有两个事务，分别是T1和T2，其中T2试图在该表级别上应用共享或排它锁，如果没有意向锁存在，那么T2就需要去检查各个页或行是否存在锁;如果存在意向锁，那么此时就会受到由T1控制的 表级别意向锁的阻塞。T2在锁定该表前不必检查各个页或行锁，而只需检査表上的意向锁。简单来说就是给更大一级别的空间示意里面是否已经上过锁。

在数据表的场景中，如果我们给某一行数据加上了排它锁，数据库会自动给更大一级的空间，比如数据页或数据表加上意向锁，告诉其他人这个数据页或数据表已经有人上过排它锁了，这样当其他人想要获取数据表排它锁的时候，只需要了解是否有人已经获取了这个数据表的意向排他锁即可。

• InnoDB 支持 多粒度锁，特定场景下，行级锁可以与表级锁共存。
• 意向锁之间互不排斥，但除了 IS与S兼容外，意向锁会与 共享锁 / 排他锁 互斥。
• IX，IS是表级锁，不会和行级的X，S锁发生冲突。只会和表级的X，S发生冲突。
• 意向锁在保证并发性的前提下，实现了 行锁和表锁共存 且 满足事务隔离性 的要求。

2.1.3 自增锁 （AUTO-INC）

AUTO-INC锁是当向使用含有AUTO_INCREMENT列的表中插入数据时需要获取的一种特殊的表级锁，在执行插入语句时就在表级别加一个AUTO-INC锁，然后为每条待插入记录的AUTO_INCREMENT修饰的列分配递增的值，在该语句执行结束后，再把AUTO-INC锁释放掉。一个事务在持有AUTO-INC锁的过程中，其他事多的插入语句都要被阻塞，可以保证一个语句中分配的递增值是连续的。也正因为此，其并发性显然并不高，当我们向一个有AUTO_INCREMENT关键字的主键插入值的时候，每条语句都要对这个表锁进行竞争，这样的并发潜力其实是很低下的，所以innodb通过innodb_autoinc_lock_mode的不同取值来提供不同的锁定机制，来显著提高SQL语句的可伸缩性和性能。

• innodb_autoinc_lock_mode = 0 (传统锁定模式)
  在此锁定模式下，所有类型的insert语句都会获得一个特殊的表级AUTO-INC锁，用于插入具有AUTO_INCREMENT列的表。这种模式每当执行insert的时候，都会得到一个表级锁(AUTO-INC锁)，使得语句中生成的auto_increment为顺序，且在binlog中重放的时候，可以保证master与slave中数据的auto_increment是相同的。因为是表级锁，当在同一时间多个事务中执行insert的时候，对于AUTO-INC锁的争夺会 限制并发 能力。
• innodb_autoinc_lock_mode = 1 (连续锁定模式)
  在 MySQL 8.0 之前，连续锁定模式是 默认 的。
  在这个模式下，“Bulk inserts”仍然使用AUTO-INC表级锁，并保持到语句结束。这适用于所有INSERT … SELECTREPLACE … SELECT和LOAD DATA语句。同一时刻只有一个语句可以持有AUTO-INC锁。
  对于“Simple inserts”(要插入的行数事先已知)，则通过在 mutex(轻量锁)的控制下获得所需数量的自动递增值来避免表级AUTO-INC锁，它只在分配过程的持续时间内保持，而不是直到语句完成。不使用表级AUTO-INC锁，除非AUTO-INC锁由另一个事务保持,如果另一个事务保持AUTO-INC锁，则“Simple inserts”等待AUTO-INC锁，如同它是一个“Bulk inserts”。
• innodb_autoinc_lock_mode = 2 (交错锁定模式)
  从 MySQL 8.0 开始，交错锁模式是 默认 设置。
  在这种锁定模式下所有类INSERT语句都不会使用表级AUTO-INC锁，并且可以同时执行多个语句。这是最快和最可扩展的锁定模式，但是当使用基于语句的复制或恢复方案时，从二进制日志重播SQL语句时，这是不安全的。
  在此锁定模式下，自动递增值 保证 在所有并发执行的所有类型的insert语句中是 唯一 且 单调递增 的。但是，由于多个语句可以同时生成数字(即，跨语句交叉编号)，为任何给定语句插入的行生成的值可能不是连续的。
  如果执行的语句是“Simple inserts”，其中要插入的行数已提前知道，除了“Mixed-mode inserts”之外，为单个语句生成的数字不会有间隙。然而，当执行“Bulk inserts”时，在由任何给定语句分配的自动递增值中可能存在间隙。

2.1.4 元数据锁 （MDL）

MDL（metadata lock）的作用是，保证读写的正确性。
如果一个查询正在遍历一个表中的数据，而执行期间另一个线程对这个表结构做变更，增加了一列，那么查询线程拿到的结果跟表结构对不上，肯定是不行的。
因此，当对一个表做增删改查操作的时候，加 MDL读锁；当要对表做结构变更操作的时候，加 MDL写锁。
读锁之间不互斥，因此你可以有多个线程同时对一张表增删改査。读写锁之间、写锁之间是互斥的，用来保证变更表结构操作的安全性，解决了DML和DDL操作之间的一致性问题。不需要显式使用，在访问一个表的时候会被自动加上。

2.2 InnoDB 行锁 Row Lock

行锁(Row Lock)也称为记录锁，顾名思义，就是锁住某一行(某条记录row)。需要的注意的是，MySQL 服务器层并没有实现行锁机制，行级锁只在存储引擎层实现。
优点：锁定力度小，发生 锁冲突概率低 ，可以实现的 并发度高。
缺点：对于 锁的开销比较大，加锁会比较慢，容易出现 死锁 情况。
InnoDB与MyISAM的最大不同有两点：一是支持事务(TRANSACTION)；二是采用了行级锁。

2.2.1 记录锁 Record Locks

记录锁也就是仅仅把一条记录锁上，官方的类型名称为:LOCK_REC_NOT_GAP。比如我们把id值为8的那条记录加一个记录锁的示意图如图所示。仅仅是锁住了id值为8的记录，对周围的数据没有影响。

记录锁是有S锁和X锁之分的，称之为 S型记录锁 和 X型记录锁。

• 当一个事务获取了一条记录的s型记录锁后，其他事务也可以继续获取该记录的s型记录锁，但不可以继续获取x型记录锁；
• 当一个事务获取了一条记录的X型记录锁后，其他事务既不可以继续获取该记录的S型记录锁，也不可以继续获取X型记录锁。

2.2.2 间隙锁 Gap Locks

MySQL 在 REPEATABLE READ 隔离级别下是可以解决幻读问题的，解决方案有两种，可以使用 MVCC 方案解决也可以采用 加锁 方案解决。但是在使用加锁方案解决时有个大问题，就是事务在第一次执行读取操作时，那些幻影记录尚不存在，我们无法给这些幻影记录加上记录锁。InnoDB提出了一种称之为 Gap Locks 的锁，官方的类型名称为: LOCK_GAP ，我们可以简称为 gap锁。

图中id值为8的记录加了gap锁，意味着不允许别的事务在id值为8的记录前边的间隙插入新记录，其实就是id列的值(3,8)这个区间的新记录是不允许立即插入的。比如，有另外一个事务再想插入一条id值为4的新记录，它定位到该条新记录的下一条记录的id值为8，而这条记录上又有一个gap锁，所以就会阻塞插入操作，直到拥有这个gap锁的事务提交了之后，id列的值在区间(3,8)中的新记录才可以被插入。
gap锁的提出仅仅是为了防止插入幻影记录而提出的。虽然有 共享gap锁 和 独占gap锁 这样的说法，但是它们起到的作用是相同的。而且如果对一条记录加了gap锁(不论是共享gap锁还是独占gap锁)，并不会限制其他事务对这条记录加记录锁或者继续加gap锁。

2.2.3 临键锁 Next-Key Locks

有时候我们既想 锁住某条记录，又想 阻止 其他事务在该记录前边的 间隙插入新记录，所以InnoDB就提出了一种称之为Next-Key Locks的锁，"官方的类型名称为：LOCK_ORDINARY，我们也可以简称为next-key锁。Next-Key Locks是在存储引擎 innodb 、事务级别在 可重复读 的情况下使用的数据库锁，innodb默认的锁就是Next-Keylocks。
next-key锁 的本质就是一个 记录锁 和一个gap锁 的合体，它既能保护该条记录，又能阻止别的事务将新记录插入被保护记录前边的 间隙。

2.2.4 插入意向锁 Insert Intention Locks

我们说一个事务在 插入 一条记录时需要判断一下插入位置是不是被别的事务加了 gap锁 (next-key锁 也包含gap锁)，如果有的话，插入操作需要等待，直到拥有gap锁 的那个事务提交。但是InnoDB规定事务在等待的时候也需要在内存中生成一个锁结构，表明有事务想在某个间隙 中插入新记录，但是现在在等待。InnoDB就把这种类型的锁命名为 Insert Intention Locks，官方的类型名称为: LOCK_INSERT_INTENTION，我们称为 插入意向锁。插入意向锁是一种 Gap锁，不是意向锁，在insert操作时产生。
插入意向锁是在插入一条记录行前，由 INSERT 操作产生的一种间隙锁。该锁用以表示插入意向，当多个事务在同一区间(gap)插入位置不同的多条数据时，事务之间不需要互相等待。假设存在两条值分别为4和7的记录，两个不同的事务分别试图插入值为5和6的两条记录，每个事务在获取插入行上独占的(排他)锁前，都会获取(4，7)之间的间隙锁，但是因为数据行之间并 不冲突，所以两个事务之间并不会产生冲突(阻塞等待)。总结来说，插入意向锁的特性可以分成两部分：

• 插入意向锁是一种 特殊的间隙锁 – 间隙锁可以锁定开区间内的部分记录。
• 插入意向锁之间互不排斥，所以即使多个事务在同一区间插入多条记录，只要记录本身(主键、唯一索引)不冲突，那么事务之间就不会出现冲突等待。

注意，虽然插入意向锁中含有意向锁三个字，但是它并不属于意向锁而属于间隙锁，因为意向锁是表锁而插入意向锁是 行锁。插入单身锁并不会阻止别的事务继续获取该记录上任何类型的锁。

2.3 页锁

页锁就是在 页的粒度 上进行锁定，锁定的数据资源比行锁要多，因为一个页中可以有多个行记录。当我们使用页锁的时候，会出现数据浪费的现象，但这样的浪费最多也就是一个页上的数据行。页锁的开销介于表锁和行锁之间，会出现死锁。锁定粒度介于表锁和行锁之间，并发度一般。
每个层级的锁数量是有限制的，因为锁会占用内存空间，锁空间的大小是有限的。当某个层级的锁数量超过了这个层级的阈值时，就会进行锁升级。锁升级就是用更大粒度的锁替代多个更小粒度的锁，比如 InnoDB 中行锁升级为表锁，这样做的好处是占用的锁空间降低了，但同时数据的并发度也下降了。

2.4 按对待锁的态度划分

这两种锁是两种看待数据并发的思维方式，乐观锁和悲观锁并不是锁，而是锁的设计思想。

2.4.1 悲观锁 Pessimistic Locking

悲观锁是一种思想，顾名思义，就是很悲观，对数据被其他事务的修改持保守态度，会通过数据库自身的锁机制来实现，从而保证数据操作的排它性。
悲观锁总是假设最坏的情况，每次去拿数据的时候都认为别人会修改，所以每次在拿数据的时候都会上锁，这样别人想拿这个数据就会 阻塞 直到它拿到锁(共享资源每次只给一个线程使用，其它线程阻塞，用完后再把资源转让给其它线程)。比如行锁，表锁等，读锁，写锁等，都是在做操作之前先上锁，当其他线程想要访问数据时，都需要阻塞挂起。Java中 synchronized 和 ReentrantLock 等独占锁就是悲观锁思想的实现（需要将执行的SQL语句放在同一个事务中，否则达不到锁定数据行的目的）。

#第1步:查出商品库存
select quantity from items where id= 1Gl for update;
#第2步:如果库存大于0，则根据商品信息生产订单
insert into orders(item_id)values(1081)
#第3步:修改商品的库存，num表示购买数量
update items set quantity= quantity-num where id = 1001

select …… for update 是MySQL中悲观锁。此时在items表中，id为1001的那条数据就被我们锁定了，其他的要执行select quantity from items where id= 1001 for update;语句的事务必须等本次事务提交之后才能执行。这样我们可以保证当前的数据不会被其它事务修改。
注意：

1. 当执行select quantity from items where id=1001 for update;语句之后，如果在其他事务中执行select quantity from items where id=1001;语句，并不会受第一个事务的影响，仍然可以正常查询出数据。
2. select… for update语句执行过程中所有扫描的行都会被锁上，因此在MySQL中用悲观锁必须确定使用了索引，而不是全表扫描，否则将会把整个表锁住。

2.4.2 乐观锁 Optimistic Locking

乐观锁认为对同一数据的并发操作不会总发生，属于小概率事件，不用每次都对数据上锁，但是在更新的时候会判断一下在此期间别人有没有去更新这个数据，也就是不采用数据库自身的锁机制，而是通过程序来实现。在程序上，我们可以采用 版本号机制 或者 CAS机制 实现。乐观锁适用于多读的应用类型，这样可以提高吞吐量。在Java中 java.util.concurrent.atomic 包下的原子变量类就是使用了乐观锁的一种实现方式：CAS实现的。

2.4.2.1 乐观锁的版本号机制

在表中设计一个版本字段 version，第一次读的时候，会获取 version 字段的取值。然后对数据进行更新或删除操作时，会执行UPDATE..SET version=version+1 WHERE version=version。此时如果已经有事务对这条数据进行了更改，修改就不会成功。
这种方式类似我们熟悉的 SVN、CVS 版本管理系统，当我们修改了代码进行提交时，首先会检查当前版本号与服务器上的版本号是否一致，如果一致就可以直接提交，如果不一致就需要更新服务器上的最新代码，然后再进行提交。

2.4.2.2 乐观锁的时间戳机制

时间戳和版本号机制一样，也是在更新提交的时候，将当前数据的时间戳和更新之前取得的时间戳进行比较，如果两者一致则更新成功，否则就是版本冲突。

2.4.2 两种锁的适用场景

从这两种锁的设计思想中，我们总结一下乐观锁和悲观锁的适用场景：
3. 乐观锁 适合 读操作多 的场景，相对来说写的操作比较少。它的优点在于 程序实现， 不存在死锁 问题，不过适用场景也会相对乐观，因为它阻止不了除了程序以外的数据库操作。
4. 悲观锁 适合 写操作多 的场景，因为写的操作具有 排它性。采用悲观锁的方式，可以在数据库层面阻止其他事务对该数据的操作权限，防止读-写和写-写的冲突。

2.5 全局锁

全局锁就是对 整个数据库实例 加锁。当你需要让整个库处于 只读状态 的时候，可以使用这个命令，之后其他线程的以下语句会被阻塞:数据更新语句(数据的增删改)、数据定义语句(包括建表、修改表结构等)和更新类事务的提交语句。全局锁的典型使用场景是：做 全库逻辑备份。

Flush tables with read lock

2.6 死锁

两个事务都持有对方需要的锁，并且在等待对方释放，并且双方都不会释放自己的锁。

2.6.1 产生死锁的必要条件

5. 两个或者两个以上事务
6. 每个事务都已经持有锁并且申请新的锁
7. 锁资源同时只能被同一个事务持有或者不兼容
8. 事务之间因为持有锁和申请锁导致彼此循环等待

2.6.2 如何处理死锁

2.6.2.1 等待，直到超时 （innodb_lock_wait_timeout=50s)

即当两个事务互相等待时，当一个事务等待时间超过设置的阈值时，就将其 回滚，另外事务继续进行。这种方法简单有效，在innodb中，参数 innodb_lock_wait_timeout 用来设置超时时间。
缺点：对于在线服务来说，这个等待时间往往是无法接受的。
那将此值修改短一些，比如1s，0.1s是否合适?不合适，容易误伤到普通的锁等待。

2.6.2.2 使用死锁检测进行死锁处理

方式1检测死锁太过被动，innodb还提供了 wait-for graph算法 来主动进行死锁检测，每当加锁请求无法立即满足需要并进入等待时，wait-for graph算法都会被触发。这是一种较为主动的死锁检测机制，要求数据库保存 锁的信息链表 和 事务等待链表 两部分信息。


一旦检测到回路、有死锁，这时候InnoDB存储引擎会选择 回滚undo量最小的事务，让其他事务继续执行(innodb_deadlock_detect=on 表示开启这个逻辑)。
缺点：每个新的被阻塞的线程，都要判断是不是由于自己的加入导致了死锁，这个操作时间复杂度是0(n)。如果100个并发线程同时更新同一行，意味着要检测100*100=1万次，1万个线程就会有1千万次检测。
如何解决

1. 关闭死锁检测，但意味着可能会出现大量的超时，会导致业务有损。
2. 控制并发访问的数量。比如在中间件中实现对于相同行的更新，在进入引擎之前排队，这样在InnoDB
   内部就不会有大量的死锁检测工作。

可以考虑通过将一行改成逻辑上的多行来减少 锁冲突。

2.6.3 如何避免死锁

• 合理设计索引，使业务 SQL尽可能通过索引定位更少的行，减少锁竞争。
• 调整业务逻辑 SQL 执行顺序，避免 update/delete 长时间持有锁的 SQL 在事务前面。
• 避免大事务，尽量将大事务拆成多个小事务来处理，小事务缩短锁定资源的时间，发生锁冲突的几率也更小。
• 在并发比较高的系统中，不要显式加锁，特别是是在事务里显式加锁。如 select …for update 语句，如果是在事务里运行了 start transaction 或设置了autocommit 等于0，那么就会锁定所查找到的记录。
• 降低隔离级别。如果业务允许，将隔离级别调低也是较好的选择，比如将隔离级别从RR调整为RC，可以避免掉很多因为gap锁造成的死锁。