锁

一、按策略来分

1. 悲观锁： 每次访问数据的时候，都要锁住数据，比如共享锁与排他锁的使用。（Mysql比如 select for update）。
2. 乐观锁： 访问数据的时候不加锁，但是还是要保持一致性，实现方法CAS或者是MVCC。

二、按粒度来分

InnoDB:支持行锁和表锁

1. 行级锁
特点： 锁的粒度最小，但是消耗的资源最多，但是并发度越高
具体实现：

• 共享锁（S Lock）： 允许事务读数据，允许多个事务共享一把锁
• 排他锁（X Lock）： 允许事务读写数据，不允许多个事务共享一把锁

2. 页级锁
特点： 开销和加锁时间界于表锁和行锁之间；会出现死锁；锁定粒度界于表锁和行锁之间，并发度一般。
具体实现：
Mysql InnoDB无，不细究

3. 表级锁
特点： 开销小，加锁快；不会出现死锁；锁定粒度大，发出锁冲突的概率最高，并发度最低。
具体实现：

• 意向共享锁（IS Lock）： 事务获取一张表某几行的共享锁
• 意向排他锁（IX Lock）： 事务获取一张表某几行的排他锁

三、按行锁的算法来分

1. Record Lock： 单行记录上的锁
2. Gap Lock： 间隙锁，锁定一个范围
3. Next-Key Lock： Gap Lock+Record Lock 锁定一个范围，并且锁定记录本身

注意Mysql innodb引擎是两段封锁协议，也就是说获取锁是一开始一起获取，在事务过程中都可以，但是释放锁是在事务结束的时候才释放的。

事务隔离级别

读未提交（read-uncommitted）

• 出现的问题： 脏读、不可重复读、幻读
• 脏读例子：
  比如要计算工资水平的人数，分为6000以下，7000以下
  张三的工资为5000,事务A中把他的工资改为8000,但事务A尚未提交。
  与此同时，
  事务B正在读取张三的工资，读取到张三的工资为8000。（7000以上+1）
  随后，
  事务A发生异常，而回滚了事务。张三的工资又回滚为5000。（实际上是6000以下+1）
  最后，
  事务B读取到的张三工资为8000的数据即为脏数据，事务B做了一次脏读。
• 解决方案（脏读）： 解决脏读的是在进行update操作的时候，加X锁，这样就进行了读提交，也就是不可重复读的隔离级别。

不可重复读（read-committed）

• 出现的问题： 不可重复读、幻读
• 不可重复读例子：
  在事务A中，读取到张三的工资为5000，操作没有完成，事务还没提交。
  与此同时，
  事务B把张三的工资改为8000，并提交了事务。
  随后，
  在事务A中，再次读取张三的工资，此时工资变为8000。在一个事务中前后两次读取的结果并不致，导致了不可重复读。
• 解决方案（不可重复读）：
  1. 如果悲观锁的话，可以通过在事务开始的时候，获取排他锁，使其它修改操作都不能执行，这样就可以解决中途被人修改的问题
  2. 如果乐观锁的话，使用MVCC的方式解决，每次进行读取的时候，都进行快照读，也就是读以前的版本，当前版本修改与以前的无关。这样就可以实现不加锁，（ps:如果这个事务查询涉及修改，那么还是需要在整个过程加X-Lock的，因为假如有两个字段：Id，Name，有一个数据[1 , Florence]，假如第一个快照读进行修改为[2,Florence]），此时还没修改完，转到第二个快照读进行修改[1,WU]，此时第二个版本提交，刷新到最新版本，然后第一个快照读进行修改，提交，这样的结果是[2,Florence],第二个快照读的修改被覆盖了

可重复读（repeatable-read，在Mysql中通过MVCC和Next-key-Lock解决了幻读问题）

• 出现的问题： 幻读
• 幻读例子：
  目前工资为5000的员工有10人，事务A读取所有工资为5000的人数为10人。
  此时，
  事务B插入一条工资也为5000的记录。
  这是，事务A再次读取工资为5000的员工，记录为11人。此时产生了幻读。
• 解决方案（幻读）：采用Next-Key Lock算法，锁住数据本身和范围内的数据。

串行化（serializable）

• 出现的问题： 无

MVCC实现原理

• 原理： InnoDB的MVCC,是通过在每行记录后面保存两个隐藏的列来实现的,这两个列，分别保存了这个行的创建时间，一个保存的是行的删除时间。这里存储的并不是实际的时间值,而是系统版本号(可以理解为事务的ID)，没开始一个新的事务，系统版本号就会自动递增，事务开始时刻的系统版本号会作为事务的ID.下面看一下在REPEATABLE READ隔离级别下,MVCC具体是如何操作的.

MVCC ReadView介绍
MySQL 的可重复读到底是怎么实现的？图解 ReadView 机制
Innodb MVCC实现原理 - 知乎 (zhihu.com)

• 快照读： MVCC中的SELECT操作是读取快照中的数据，不需要进行加锁；
• 当前读： MVCC中修改数据的操作（增删改）需要进行加锁操作，从而读取最新的数据；

SELECT

InnoDB 会根据以下两个条件检查每行记录：

InnoDB只查找版本早于当前事务版本的数据行（也就是，行的事务编号小于或等于当前事务的事务编号），这样可以确保事务读取的行，要么是在事务开始前已经存在的，要么是事务自身插入或者修改过的。

删除的行要事务ID判断，读取到事务开始之前状态的版本，只有符合上述两个条件的记录，才能返回作为查询结果。

INSERT

InnoDB为新插入的每一行保存当前事务编号作为行版本号。

DELETE

InnoDB为删除的每一行保存当前事务编号作为行删除标识。

UPDATE

InnoDB为插入一行新记录，保存当前事务编号作为行版本号，同时保存当前事务编号到原来的行作为行删除标识。

然后获取以前版本的信息是通过undo log 来实现的

• MVVC在隔离级别中解决的问题：MySQL通过MVCC(解决读写并发问题)和间隙锁（解决写写并发问题）来解决不可重复读和幻读，首先读写并发用MVCC就足够解决幻读问题了，因为读的版本已经跟更新的版本不同，但是如果是写写并发的话，可能会导致丢失更新的情况

例子：假如有两个字段：Id，Name，有一个数据[1 , Florence]，假如第一个快照读进行修改为[2,Florence]），此时还没修改完，转到第二个快照读进行修改[1,WU]，此时第二个版本提交，刷新到最新版本，然后第一个快照读进行修改，提交，这样的结果是[2,Florence],第二个快照读的修改被覆盖了，上面是不可重复读的例子，幻读**的同理

在读提交(RC)，可重复读(RR)两个不同的事务的隔离级别下，快照读有什么不同呢？RC下，快照读总是能读到最新的行数据快照，当然，必须是已提交事务写入的。RR下，某个事务首次read记录的时间为T，未来不会读取到T时间之后已提交事务写入的记录，以保证连续相同的read读到相同的结果集。所以RC存在着幻读和不可重复读，而RP下全都解决了。