演示-插入意向锁
会话A
mysql> begin; Query OK, 0 rows affected (0.00 sec) mysql> select * from student where id =12 for update; Empty set (0.00 sec) mysql>
会话B
mysql> begin; Query OK, 0 rows affected (0.00 sec) mysql> insert into student(id,name,class)values(11,'Tim','一班'); #等待 生成一个锁结构 LOCK_INSERT_INTENTION
演示-插入意向锁可兼容
会话C
mysql> begin; Query OK, 0 rows affected (0.00 sec) mysql> insert into student(id,name,class)values(12,'Tim','一班'); #等待
会话A
mysql> commit; Query OK, 0 rows affected (0.00 sec)
会话B&C
#B执行 Query OK, 1 row affected (4.51 sec) #C执行 Query OK, 1 row affected (2.16 sec)
3. 页锁
页锁就是在 页的粒度 上进行锁定，锁定的数据资源比行锁要多，因为一个页中可以有多个行记录。当使用页锁的时候，会出现数据浪费的现象，但这样的浪费最多也就是一个页上的数据行。页锁的开销介于表锁和行锁之间，会出现死锁。锁定粒度介于表锁和行锁之间，并发度一般。
每个层级的锁数量是有限制的，因为锁会占用内存空间， 锁空间的大小是有限的 。当某个层级的锁数量超过了这个层级的阈值时，就会进行 锁升级 。锁升级就是用更大粒度的锁替代多个更小粒度的锁，比如InnoDB 中行锁升级为表锁，这样做的好处是占用的锁空间降低了，但同时数据的并发度也下降了。
3.3 从对待锁的态度划分:乐观锁、悲观锁
从对待锁的态度来看锁的话，可以将锁分成乐观锁和悲观锁，从名字中也可以看出这两种锁是两种看待数据并发的思维方式 。需要注意的是，乐观锁和悲观锁并不是锁，而是锁的 设计思想 。
1. 悲观锁（Pessimistic Locking）
悲观锁是一种思想，顾名思义，就是很悲观，对数据被其他事务的修改持保守态度，会通过数据库自身的锁机制来实现，从而保证数据操作的排它性。
悲观锁总是假设最坏的情况，每次去拿数据的时候都认为别人会修改，所以每次在拿数据的时候都会上锁，这样别人想拿这个数据就会 阻塞 直到它拿到锁（共享资源每次只给一个线程使用，其它线程阻塞，用完后再把资源转让给其它线程）。比如行锁，表锁等，读锁，写锁等，都是在做操作之前先上锁，当其他线程想要访问数据时，都需要阻塞挂起。Java中 synchronized 和 ReentrantLock 等独占锁就是悲观锁思想的实现。
秒杀案例1:
商品秒杀过程中，库存数量的减少，避免出现超卖的情况。比如，商品表中有一个字段为quantity表示当前该商品的库存量。假设商品为华为mate40，id为1001，quantity=100个。如果不使用锁的情况下，操作方法如下所示:
#第1步:查出商品库存 select quantity from items where id = 1001 ; #第2步:如果库存大于0，则根据商品信息生产订单 insert into orders (item_id）values ( 1001 ) ; #第3步:修改商品的库存，num表示购买数量 update items set quantity = quantity-num where id = 1001 ;
这样写的话，在并发量小的公司没有大的问题，但是如果在高并发环境下可能出现以下问题
线程A |
线程B | |
| 1 | step1(查询还有100部手机) | step1(查询还有100部手机) |
| 2 | step2(生成订单) | |
| 3 | step2(生成订单) | |
| 4 | step3(减库存1) | |
| 5 | step3(减库存2) |
其中线程B此时已经下单并且减完库存，这个时候线程A依然去执行step3，就造成了超卖。
我们使用悲观锁可以解决这个问题，商品信息从查询出来到修改，中间有一个生成订单的过程，使用悲观锁的原理就是，在查询items信息后就把当前的数据锁定，直到修改完毕后再解锁。那么整个过程中，因为数据被锁定了，就不会出现有第三者来对其进行修改了。而这样做的前提是需要将要执行的SQL语句放在同一个事务中，否则达不到锁定数据行的目的。
修改如下:
#第1步:查出商品库存 select quantity from items where id = 1001 for update; #第2步:如果库存大于0，则根据商品信息生产订单 insert into orders (item_id)values(1001); #第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;语句的事务必须等本次事务提交之后才能执行。这样可以保证当前的数据不会被其它事务修改。
注意，当执行select quantity from items where id = 1001 for update;语句之后，如果在其他事务中执行select quantity from items where id = 1001;语句，并不会受第一个事务的影响，仍然可以正常查询出数据。
注意:
select … for update语句执行过程中所有扫描的行都会被锁上，因此在MySQL中用悲观锁必须确定使用了索引，而不是全表扫描，否则将会把整个表锁住。
悲观锁不适用的场景较多，它存在一些不足，因为悲观锁大多数情况下依靠数据库的锁机制来实现，以保证程序的并发访问性，同时这样对数据库性能开销影响也很大，特别是长事务而言，这样的开销往往无法承受，这时就需要乐观锁。
2. 乐观锁（Optimistic Locking）
乐观锁认为对同一数据的并发操作不会总发生，属于小概率事件，不用每次都对数据上锁，但是在更新的时候会判断一下在此期间别人有没有去更新这个数据，也就是不采用数据库自身的锁机制，而是通过程序来实现。在程序上，可以采用 版本号机制 或者 CAS机制 实现。乐观锁适用于多读的应用类型，这样可以提高吞吐量。在Java中java.util.concurrent.atomic 包下的原子变量类就是使用了乐观锁的一种实现方式：CAS实现的。
1. 乐观锁的版本号机制
在表中设计一个 版本字段 version ，第一次读的时候，会获取 version 字段的取值。然后对数据进行更新或删除操作时，会执行 UPDATE … SET version=version+1 WHERE version=version 。此时如果已经有事务对这条数据进行了更改，修改就不会成功。
这种方式类似我们熟悉的SVN、CVS版本管理系统，当修改了代码进行提交时，首先会检查当前版本号与服务器上的版本号是否一致，如果一致就可以直接提交，如果不一致就需要更新服务器上的最新代码，然后再进行提交。
2. 乐观锁的时间戳机制
时间戳和版本号机制一样，也是在更新提交的时候，将当前数据的时间戳和更新之前取得的时间戳进行比较，如果两者一致则更新成功，否则就是版本冲突。
能看到乐观锁就是程序员自己控制数据并发操作的权限，基本是通过给数据行增加一个戳(版本号或者时间戳)，从而证明当前拿到的数据是否最新。
秒杀案例2
依然使用上面秒杀的案例，执行流程如下
#第1步:查出商品库存 select quantity from items where id = 1001; #第2步:如果库存大于0，则根据商品信息生产订单 insert into orders (item_id）values (1001); #第3步:修改商品的库存,num表示购买数量 update items set quantity = quantity-num , version = version+1 where id = 1001 and version = #{version} ;
注意，如果数据表是读写分离的表，当matser表中写入的数据没有及时同步到slave表中时，会造成更新一直失败的问题。此时需要强制读取master表中的数据（即将select语句放到事务中即可，这时候查询的就是master主库了)
如果对同一条数据进行频繁的修改的话，那么就会出现这么一种场景，每次修改都只有一个事务能更新成功，在业务感知上面就有大量的失败操作。我们把代码修改如下:
#第1步:查出商品库存 select quantity from items where id = 1001; #第2步:如果库存大于0，则根据商品信息生产订单 insert into orders (item_id)values(1001); #第3步:修改商品的库存，num表示购买数量 update items set quantity = quantity-num where id = 1001 and quantity-num>6;
这样就会使每次修改都能成功，而且不会出现超卖的现象。
3. 两种锁的适用场景
从这两种锁的设计思想中，总结一下乐观锁和悲观锁的适用场景：
1.乐观锁 适合 读操作多 的场景，相对来说写的操作比较少。它的优点在于 程序实现 ， 不存在死锁问题，不过适用场景也会相对乐观，因为它阻止不了除了程序以外的数据库操作。
2.悲观锁 适合 写操作多 的场景，因为写的操作具有 排它性 。采用悲观锁的方式，可以在数据库层面阻止其他事务对该数据的操作权限，防止 读 - 写 和 写 - 写 的冲突。
把乐观锁和悲观锁总结如下图所示
3.4按加锁的方式划分:显式锁、隐式锁
1.隐式锁
一个事务在执行INSERT操作时，如果即将插入的间隙已经被其他事务加了gap锁，那么本次INSERT操作会阻塞，并且当前事务会在该间隙上加一个插入意向锁，否则一般情况下INSERT操作是不加锁的。
那如果一个事务首先插入了一条记录（此时并没有在内存生产与该记录关联的锁结构)，然后另一个事务:
立即使用SELECT … LOCK IN SHARE MODE语句读取这条记录，也就是要获取这条记录的S锁，或者使用SELECT… FOR UPDATE语句读取这条记录，也就是要获取这条记录的X锁，怎么办?
如果允许这种情况的发生，那么可能产生脏读问题。
立即修改这条记录，也就是要获取这条记录的x锁，怎么办?
如果允许这种情况的发生，那么可能产生脏写问题。
这时候前边提过的事务id又要起作用了。把聚簇索引和二级索引中的记录分开看一下:
**情景一：**对于聚簇索引记录来说，有一个 trx_id 隐藏列，该隐藏列记录着最后改动该记录的 事务id 。那么如果在当前事务中新插入一条聚簇索引记录后，该记录的 trx_id 隐藏列代表的的就是当前事务的 事务id ，如果其他事务此时想对该记录添加 S锁 或者 X锁 时，首先会看一下该记录的trx_id 隐藏列代表的事务是否是当前的活跃事务，如果是的话，那么就帮助当前事务创建一个 X锁 （也就是为当前事务创建一个锁结构， is_waiting 属性是 false ），然后自己进入等待状态（也就是为自己也创建一个锁结构， is_waiting 属性是 true ）。
**情景二：**对于二级索引记录来说，本身并没有 trx_id 隐藏列，但是在二级索引页面的 Page Header 部分有一个 PAGE_MAX_TRX_ID 属性，该属性代表对该页面做改动的最大的 事务id ，如果 PAGE_MAX_TRX_ID 属性值小于当前最小的活跃 事务id ，那么说明对该页面做修改的事务都已经提交了，否则就需要在页面中定位到对应的二级索引记录，然后回表找到它对应的聚簇索引记录，然后再重复 情景一 的做法。
即：一个事务对新插入的记录可以不显式的加锁（生成一个锁结构），但是由于事务id的存在，相当于加了一个隐式锁。别的事务在对这条记录加S锁或者X锁时，由于隐式锁的存在，会先帮助当前事务生成一个锁结构，然后自己再生成一个锁结构后进入等待状态。隐式锁是一种延迟加锁的机制，从而来减少加锁的数量。
隐式锁在实际内存对象中并不含有这个锁信息。只有当产生锁等待时，隐式锁转化为显式锁。
InnoDB的insert操作，对插入的记录不加锁，但是此时如果另一个线程进行当前读，类似以下的用例，session 2会锁等待session 1，那么这是如何实现的呢?
session 1:
begin ; insert INTO student VALUES(34,"周八”,"二班");
session 2:
begin; select * from student lock in share mode; #执行完，当前事务被阻塞
执行下述语句，输出结果:
SELECT * FROM performance_schema.data_lock_waits\G; /* SELECT * FROM performance_schema.data_lock_waits\G; *************************** 1. row *************************** ENGINE: INNODB REQUESTING_ENGINE_LOCK_ID: 140562531358232:7:4:9:140562535668584 REQUESTING_ENGINE_TRANSACTION_ID: 422037508068888 REQUESTING_THREAD_ID: 64 REQUESTING_EVENT_ID: 6 REQUESTING_OBJECT_INSTANCE_BEGIN: 140562535668584 BLOCKING_ENGINE_LOCK_ID: 140562531351768:7:4:9:140562535619104 BLOCKING_ENGINE_TRANSACTION_ID: 15902 BLOCKING_THREAD_ID: 64 BLOCKING_EVENT_ID: 6 BLOCKING_OBJECT_INSTANCE_BEGIN: 140562535619104 1 row in set (0.00 sec) */
隐式锁的逻辑过程如下：
A. InnoDB的每条记录中都一个隐含的trx_id字段，这个字段存在于聚簇索引的B+Tree中。
B. 在操作一条记录前，首先根据记录中的trx_id检查该事务是否是活动的事务(未提交或回滚)。如果是活动的事务，首先将 隐式锁 转换为 显式锁 (就是为该事务添加一个锁)。
C. 检查是否有锁冲突，如果有冲突，创建锁，并设置为waiting状态。如果没有冲突不加锁，跳到E。
D. 等待加锁成功，被唤醒，或者超时。
E. 写数据，并将自己的trx_id写入trx_id字段。
2.显式锁
通过特定的语句进行加锁，一般称之为显示加锁，例如:
显示加共享锁:
select ....lock in share mode;
显示加排它锁:
select ....for update;
3.5其它锁之:全局锁
全局锁就是对整个数据库实例加锁。当你需要让整个库处于只读状态的时候，可以使用这个命令，之后其他线程的以下语句会被阻塞:数据更新语句(数据的增删改)、数据定义语句（包括建表、修改表结构等）和更新类事务的提交语句。全局锁的典型使用场景是:做全库逻辑备份。
全局锁的命令:
Flush tables with read lock
3.6其它锁之:死锁
1.概念
死锁是指两个或多个事务在同一资源上相互占用，并请求锁定对方占用的资源，从而导致恶性循环。死锁举例如下：
举例一：
这时候，事务1在等待事务2释放id=2的行锁，而事务2在等待事务1释放id=1的行锁。 事务1和事务2在互相等待对方的资源释放，就是进入了死锁状态。当出现死锁以后，有 两种策略 ：
一种策略是，直接进入等待，直到超时。这个超时时间可以通过参数innodb_lock_wait_timeout 来设置。
另一种策略是，发起死锁检测，发现死锁后，主动回滚死锁链条中的某一个事务（将持有最少行级排他锁的事务进行回滚），让其他事务得以继续执行。将参数innodb_deadlock_detect 设置为on ，表示开启这个逻辑。
在InnoDB中，innodb_lock_wait_timeout的默认值是50s,意味着如果采用第一个策略，当出现死锁以后,第一个被锁住的线程要过50s才会超时退出，然后其他线程才有可能继续执行。对于在线服务来说，这个等待时间往往是无法接受的。
但是，我们又不可能直接把这个时间设置成一个很小的值，比如1s。这样当出现死锁的时候，确实很快就可以解开，但如果不是死锁，而是简单的锁等待呢？所以，超时时间设置太短的话，会出现很多误伤。
举例2:
用户A给用户B转账100，在此同时，用户B也给用户A转账100。这个过程，可能导致死锁。
#事务1 update account set balance = balance - 108 where name = 'A';#操作1 update account set balance = balance + 100 where name = 'B');#操作3 #事务2 update account set balance = balance - 100 where name = 'B';#操作2 update account set balance = balance + 100 where name = 'A';#操作4
2.产生死锁的必要条件
- 两个或者两个以上事务
- 每个事务都已经持有锁并且申请新的锁
- 锁资源同时只能被同一个事务持有或者不兼容
- 事务之间因为持有锁和申请锁导致彼此循环等待
死锁的关键在于:两个(或以上)的Session加锁的顺序不一致。
演示-死锁
会话A&B
mysql> use atguigudb3; Reading table information for completion of table and column names You can turn off this feature to get a quicker startup with -A Database changed mysql> select * from account; +----+--------+---------+ | id | name | balance | +----+--------+---------+ | 1 | 张三 | 40 | | 2 | 李四 | 0 | | 3 | 王五 | 100 | | 4 | 马六 | 1000 | +----+--------+---------+ 4 rows in set (0.01 sec)
会话A
mysql> begin; Query OK, 0 rows affected (0.01 sec) mysql> update account set balance = balance - 10 where id =1; Query OK, 1 row affected (0.01 sec) Rows matched: 1 Changed: 1 Warnings: 0
会话B
mysql> begin; Query OK, 0 rows affected (0.00 sec) mysql> update account set balance = balance - 10 where id =3; Query OK, 1 row affected (0.00 sec) Rows matched: 1 Changed: 1 Warnings: 0
会话B
mysql> update account set balance = balance + 10 where id =1; ERROR 1213 (40001): Deadlock found when trying to get lock; try restarting transaction # commmit;
3.如何处理死锁
**方式1:**等待，直到超时( innodb_lock_wait_timeout=50s)
即当两个事务互相等待时，当一个事务等待时间超过设置的阈值时，就将其回滚，另外事务继续进行。这种方法简单有效，在innodb中，参数innodb_lock_wait_timeout用来设置超时时间。
缺点:对于在线服务来说，这个等待时间往往是无法接受的。
那将此值修改短一些，比如1s，0.1s是否合适?不合适，容易误伤到普通的锁等待。
mysql> show variables like 'innodb_lock_wait_timeout'; +--------------------------+-------+ | Variable_name | Value | +--------------------------+-------+ | innodb_lock_wait_timeout | 50 | +--------------------------+-------+ 1 row in set (0.02 sec)
**方式2:**使用死锁检测进行死锁处理
方式1检测死锁太过被动，innodb还提供了wait-for graph算法来主动进行死锁检测，每当加锁请求无法立即满足需要并进入等待时，wait-for graph算法都会被触发。
这是一种较为主动的死锁检测机制，要求数据库保存锁的信息链表和事务等待链表两部分信息。
基于这两个信息，可以绘制wait-for graph 等待图)
死锁检测的原理是构建一个以事务为顶点、锁为边的有向图，判断有向图是否存在环，存在即有死锁
一旦检测到回路、有死锁，这时候InnoDB存储引擎会选择回滚undo量最小的事务，让其他事务继续执行( innodb_deadlock_detect=on表示开启这个逻辑)。
缺点:每个新的被阻塞的线程，都要判断是不是由于自己的加入导致了死锁，这个操作时间复杂度是o(n)。如果100个并发线程同时更新同一行，意味着要检测100*100= 1万次，1万个线程就会有1千万次检测。
如何解决?
方式1:关闭死锁检测，但意味着可能会出现大量的超时，会导致业务有损。
方式2:控制并发访问的数量。比如在中间件中实现对于相同行的更新，在进入引擎之前排队，这样在InnoDB内部就不会有大量的死锁检测工作
进一步的思路:
可以考虑通过将一行改成逻辑上的多行来减少锁冲突。比如，连锁超市账户总额的记录，可以考虑放到多条记录上。账户总额等于这多个记录的值的总和。
4.如何避免死锁
- 合理设计索引，使业务SQL尽可能通过索引定位更少的行，减少锁竞争。
- 调整业务逻辑SQL执行顺序，避免update/delete长时间持有锁的SQL在事务前面。
- 避免大事务，尽量将大事务拆成多个小事务来处理，小事务缩短锁定资源的时间，发生锁冲突的几率也更小
- 在并发比较高的系统中，不要显式加锁，特别是是在事务里显式加锁。如select … for
- update语句，如果是在事务里运行了start transaction或设置了autocommit等于0，那么就会锁定所查找到的记录
- 降低隔离级别。如果业务允许，将隔离级别调低也是较好的选择，比如将隔离级别从RR调整为RC，可以避免掉很多因为gap锁造成的死锁。
4.锁的内存结构
前边说对一条记录加锁的本质就是在内存中创建一个锁结构与之关联，那么是不是一个事务对多条记录加锁，就要创建多个锁结构呢?比如:
#事务T1 SELECT * FROM user LOCK IN SHARE MODE;
理论上创建多个锁结构没问题，但是如果一个事务要获取10000条记录的锁，生成10000个锁结构也太崩溃了!所以决定在对不同记录加锁时，如果符合下边这些条件的记录会放到一个锁结构中。
在同一个事务中进行加锁操作
被加锁的记录在同一个页面中
加锁的类型是一样的
等待状态是一样的
InnoDB存储引擎中的锁结构如下:
结构解析：
1. 锁所在的事务信息 ：
不论是表锁 还是 行锁 ，都是在事务执行过程中生成的，哪个事务生成了这个 锁结构 ，这里就记录这个事务的信息。
此 锁所在的事务信息 在内存结构中只是一个指针，通过指针可以找到内存中关于该事务的更多信息，比方说事务id等。
2. 索引信息 ：
对于 行锁 来说，需要记录一下加锁的记录是属于哪个索引的。这里也是一个指针。
3. 表锁／行锁信息 ：
表锁结构 和 行锁结构 在这个位置的内容是不同的：
表锁：
记载着是对哪个表加的锁，还有其他的一些信息。
行锁：
记载了三个重要的信息：
Space ID ：记录所在表空间。
Page Number ：记录所在页号。
n_bits ：对于行锁来说，一条记录就对应着一个比特位，一个页面中包含很多记录，用不同的比特位来区分到底是哪一条记录加了锁。为此在行锁结构的末尾放置了一堆比特位，这个n_bits 属性代表使用了多少比特位
n_bits的值一般都比页面中记录条数多一些。主要是为了之后在页面中插入了新记录后也不至于重新分配锁结构
4. type_mode ：
这是一个32位的数，被分成了 lock_mode 、 lock_type 和 rec_lock_type 三个部分，如图所示：
锁的模式（ lock_mode ），占用低4位，可选的值如下：
LOCK_IS （十进制的 0 ）：表示共享意向锁，也就是 IS锁
LOCK_IX （十进制的 1 ）：表示独占意向锁，也就是 IX锁 。
LOCK_S （十进制的 2 ）：表示共享锁，也就是 S锁 。
LOCK_X （十进制的 3 ）：表示独占锁，也就是 X锁 。
LOCK_AUTO_INC （十进制的 4 ）：表示 AUTO-INC锁 。
在InnoDB存储引擎中，LOCK_IS,LOCK_IX，LOCK_AUTO_INC都算是表级锁的模式，LOCK_S和LOCK_X既可以算是表级锁的模式，也可以是行级锁的模式
锁的类型（ lock_type ），占用第5～8位，不过现阶段只有第5位和第6位被使用：
LOCK_TABLE （十进制的 16 ），也就是当第5个比特位置为1时，表示表级锁。
LOCK_REC （十进制的 32 ），也就是当第6个比特位置为1时，表示行级锁。
行锁的具体类型（ rec_lock_type ），使用其余的位来表示。只有在 lock_type 的值为LOCK_REC 时，也就是只有在该锁为行级锁时，才会被细分为更多的类型：
LOCK_ORDINARY （十进制的 0 ）：表示 next-key锁 。
LOCK_GAP （十进制的 512 ）：也就是当第10个比特位置为1时，表示 gap锁 。
LOCK_REC_NOT_GAP （十进制的 1024 ）：也就是当第11个比特位置为1时，表示正经 记录锁 。
LOCK_INSERT_INTENTION （十进制的 2048）：也就是当第12个比特位置为1时，表示插入意向锁。其他的类型：还有一些不常用的类型我们就不多说了。
is_waiting 属性呢？基于内存空间的节省，所以把 is_waiting 属性放到了 type_mode 这个32位的数字中：
LOCK_WAIT （十进制的 256 ） ：当第9个比特位置为 1 时，表示 is_waiting 为 true ，也就是当前事务尚未获取到锁，处在等待状态；当这个比特位为 0 时，表示 is_waiting 为false ，也就是当前事务获取锁成功。
5. 其他信息 ：
为了更好的管理系统运行过程中生成的各种锁结构而设计了各种哈希表和链表。
6. 一堆比特位 ：
如果是 行锁结构 的话，在该结构末尾还放置了一堆比特位，比特位的数量是由上边提到的 n_bits 属性表示的。InnoDB数据页中的每条记录在 记录头信息 中都包含一个 heap_no 属性，伪记录 Infimum 的heap_no 值为0 ， Supremum 的 heap_no 值为 1 ，之后每插入一条记录， heap_no 值就增1。 锁结构 最后的一堆比特位就对应着一个页面中的记录，一个比特位映射一个 heap_no ，即一个比特位映射到页内的一条记录。
