MYSQL的锁
根据加锁的范围，MYSQL里面的锁大致可分为全局锁，表级锁和行锁
全局锁会让整个库处于只读状态，一个典型场景就是做全库逻辑备份。
表锁一般是在数据库引擎不支持行锁的时候才会被用到的。如果你发现你的应用程序里有 lock tables 这样的语句，可能时使用MyISAM引擎导致，那要安排升级换引擎。
行锁是引擎层自己实现的，行锁就是针对数据库行记录的锁，比如事务 A 更新了一行，而这时候事务 B 也要更新同一行，则必须等事务 A 的操作完成后才能进行更新。行锁是在执行的时候加，事务提交的时候释放。如果你的事务中需要锁多个行，要把最可能造成锁冲突、最可能影响并发度的锁尽量往后放。
事务与行锁的关系
在讲MYSQL事务隔离的时候，事务T启动会创建视图read-view，之后即使其他事务修改了数据，事务T看到的数据依然是和启动时相同
但是Innodb引擎的行锁，事务更新一行，如果刚好其他事务持有这一行的行锁，这个事务不能更新这行数据，会被锁住，那么等到这个事务自己获取到行锁要更新数据的时候，它读到的值又是什么呢？
mysql> CREATE TABLE `t` (
`id` int(11) NOT NULL,
`k` int(11) DEFAULT NULL,
PRIMARY KEY (`id`)
) ENGINE=InnoDB;
insert into t(id, k) values(1,1),(2,2);
| 事务A | 事务B | 事务C |
|---|---|---|
| start transaction with consistent snapshot | ||
| start transaction with consistent snapshot | ||
| update t set k = k+1 where id= 1 | ||
| update t set k = k+1 where id= 1;select k from t where id =1; | ||
| select k from t where id =1 ;comit; | ||
| comit; | ||
| 事务 C 没有显式地使用 begin/commit，表示这个 update 语句本身就是一个事务，语句完成的时候会自动提交 | ||
| 在 MySQL 里，有两个“视图”的概念： |
- 一种是虚拟表，通过CREATE VIEW以及查询语句生成
- 另一个是 InnoDB 在实现 MVCC 时用到的一致性读视图，用于支持 RC（Read Committed，读提交）和 RR（Repeatable Read，可重复读）隔离级别的实现。
在 MVCC 里是怎么工作的？
在可重复读隔离级别下，事务在启动的时候就“拍了个快照”。注意，这个快照是基于整库的。
InnoDB 里面每个事务有一个唯一的事务 ID，叫作 transaction id。是按申请顺序严格递增的。
每次事务更新数据的时候，都会生成一个新的数据版本，并且把 transaction id 赋值给这个数据版本的事务 ID，记为 row trx_id。在新的数据版本中，指向旧版本的指针。
可重复读的定义，一个事务启动的时候，能够看到所有已经提交的事务结果。但是之后，这个事务执行期间，其他事务的更新对它不可见。数据版本可不可见的关键在于是否是我当前事务开启之前生成的，因此，InnoDB 为每个事务构造了一个数组，用来保存这个事务启动瞬间，当前启动但是没有提交的trx_id。他的左侧数组最小值，右侧时最大值+1。
- 小于这个最小值表示已提交事务，或者当前事务生成的，这部分数据可见。
- 大于等于最大值表示时将来事务生成的，这部分数据不可见。
- 如果trx_id在这个数组区间范围内
1> 若 row trx_id 在数组中，表示这个版本是由还没提交的事务生成的，不可见；
2> 若 row trx_id 不在数组中，表示这个版本是已经提交了的事务生成的，可见。
在这个范围里面并不意味这这个范围里有这个值，比如[1,2,3,5]，4在这个数组1-5的范围里，却没在这个数组里面。换句话说，小于最小值的一定可见，但是可见的不一定小于这个最小值。
对于上面的状态变更来说，如果有一个事务，它的低水位是 18，那么当它访问这一行数据时，就会从 V4 通过 U3 计算出 V3，所以在它看来，这一行的值是 11。
假设表格
- 事务 A 开始前，系统里面只有一个活跃事务 ID 是 99；
- 事务 A、B、C 的版本号分别是 100、101、102，且当前系统里只有这四个事务；
- 三个事务开始前，(1,1）这一行数据的 row trx_id 是 90。
这样，事务 A 的视图数组就是[99,100], 事务 B 的视图数组是[99,100,101], 事务 C 的视图数组是[99,100,101,102]
第一个有效更新是事务 C，把数据从 (1,1) 改成了 (1,2)。这时候，这个数据的最新版本的 row trx_id 是 102，而 90 这个版本已经成为了历史版本。
第二个有效更新是事务 B，把数据从 (1,2) 改成了 (1,3)。这时候，这个数据的最新版本（即 row trx_id）是 101，而 102 又成为了历史版本。更新的时候是当前读，读取最新已提交的事务，他的事务id是101，可以读取到更新的数据。
在事务 A 查询的时候，其实事务 B 还没有提交，但是它生成的 (1,3) 这个版本已经变成当前版本了
现在事务 A 要来读数据了，它的视图数组是[99,100]
- 找到 (1,3) 的时候，判断出 row trx_id=101，比高水位大，处于红色区域，不可见；
- 接着，找到上一个历史版本，一看 row trx_id=102，比高水位大，处于红色区域，不可见；
- 再往前找，终于找到了（1,1)，它的 row trx_id=90，比低水位小，处于绿色区域，可见。
一个数据版本，对于一个事务视图来说，除了自己的更新总是可见以外，有三种情况：
- 版本未提交，不可见；
- 版本已提交，但是是在视图创建后提交的，不可见；
- 版本已提交，而且是在视图创建前提交的，可见。
按照这个逻辑来的话
- (1,3) 还没提交，属于情况 1，不可见；
- (1,2) 虽然提交了，但是是在视图数组创建之后提交的，属于情况 2，不可见；
- 1,1) 是在视图数组创建之前提交的，可见。
更新逻辑
要去更新数据的时候，就不能再在历史版本上更新了，否则事务 C 的更新就丢失了。因此，事务 B 此时的 set k=k+1 是在（1,2）的基础上进行的操作。
更新数据都是先读后写的，而这个读，只能读当前的值，称为“当前读”。
因此，在更新的时候，当前读拿到的数据是 (1,2)，更新后生成了新版本的数据 (1,3)，这个新版本的 row trx_id 是 101。所以，在执行事务 B 查询语句的时候，一看自己的版本号是 101，最新数据的版本号也是 101，是自己的更新，可以直接使用，所以查询得到的 k 的值是 3。
这里我们提到了一个概念，叫作当前读。其实，除了 update 语句外，select 语句如果加锁，也是当前读。
如果把事务 A 的查询语句 select * from t where id=1 修改一下，加上 lock in share mode 或 for update，也都可以读到版本号是 101 的数据，返回的 k 的值是 3。下面这两个 select 语句，就是分别加了读锁（S 锁，共享锁）和写锁（X 锁，排他锁）。
事务 C’的不同是，更新后并没有马上提交，在它提交前，事务 B 的更新语句先发起了。前面说过了，虽然事务 C’还没提交，但是 (1,2) 这个版本也已经生成了，并且是当前的最新版本。那么，事务 B 的更新语句会怎么处理呢？
事务 C’没提交，也就是说 (1,2) 这个版本上的写锁还没释放。而事务 B 是当前读，必须要读最新版本，而且必须加锁，因此就被锁住了，必须等到事务 C’释放这个锁，才能继续它的当前读。
一致性读依赖mvcc快照，利用事务id递增特性，来做读取数据时历史版本的选择；当前读实际上是由行锁来实现的，持有行锁的更新操作才能进行当前读，否则更新操作会阻塞
而读提交的逻辑和可重复读的逻辑类似，它们最主要的区别是：
- 在可重复读隔离级别下，只需要在事务开始的时候创建一致性视图，之后事务里的其他查询都共用这个一致性视图；
- 在读提交隔离级别下，每一个语句执行前都会重新算出一个新的视图。
总之
InnoDB 的行数据有多个版本，每个数据版本有自己的 row trx_id，每个事务或者语句有自己的一致性视图。普通查询语句是一致性读，一致性读会根据 row trx_id 和一致性视图确定数据版本的可见性。对于可重复读，查询只承认在事务启动前就已经提交完成的数据；对于读提交，查询只承认在语句启动前就已经提交完成的数据；