事务号 transaction id, undo log

InnoDB 里面每个事务有一个唯一的事务 ID， transaction id。它是在事务开始的时候(第一个操作)向 InnoDB 的事务系统申请的，是按申请顺序严格递增的。

数据表中的一行记录，可能有多个版本 (row)。每个版本是每次事务更新数据的时候产生的, 每个版本有个row trx_id, 就是 transaction id . 同时，旧的数据版本要保留，并且在新的数据版本中,可以访问到老的版本(通过undo log )

如: 当前最新版本是 V4，k 的值是 22，它是被 transaction id = 25 的事务更新的，因此它的 row trx_id 也是 25。

U1,U2,U3 这些箭头就是 undo log
V1、V2、V3 并不真实存在的，
而是每次需要的时候根据当前版本和 undo log (箭头后退)计算出来的。

一致性视图（read-view）

可重复读 (mysql默认隔离级别):
数据库里在事务启动时创建一个视图,
(start transaction with consistent snapshot; 开始视图, 这句只有在可重复读时有效, 读提交 时 只是普通的开始事务)
整个事务存在期间看到的值都用这个视图。
就是 这个事务启动的时刻为准，如果一个数据版本(row trx_id)是在启动之前生成的，就不可见, 继续往前找( 用undo log回退 )。

在实现上， InnoDB 为每个事务构造了一个数组，用来保存这个事务启动瞬间，当前正在“活跃”(事务启动并还没提交)的所有事务 ID, 这些事务虽然在本事务之前,但是还没提交,之后也可能更新

数组里面事务 ID 的最小值记为低水位，
当前系统里面已经创建过的事务 ID 的最大值加 1 记为高水位

高水位不一定是自己, 因为事务启动申请自己的事务 和 构造这个数组 之间有时间差, 可能有其他事务产生

start transaction;之后
第一次操作才产生视图,
start transaction; 和select之间有其他事务的更新提交了, 会被算做之后的事务,纳入本事务快照读承认的快照

就是当前事务的 一致性视图（read-view）。

对于当前事务的,一行数据版本的 row trx_id，有以下几种可能：

1.绿色: 我开始前提交的,直接可见
2.红色: 我开始后开始的,直接不可见
3.黄色, 需要查数组,
数组里面: 我开始时还没提交 不可见
不在里面就可见

因为先开始的事务,不一定先提交, 在黄色区域的 事务7在本事务开始前提交了(可见),在他之前的事务6却没有提交
这样分3段就可以迅速判断一下, 在黄色区域再进一步查数据

例子

事务 A 开始前，系统里面只有一个活跃事务 ID 是 99；

事务 A、B、C 的版本号分别是 100、101、102，且当前系统里只有这四个事务；

三个事务开始前，(1,1）这一行数据的 row trx_id 是 90。

事务 A(100) 数组: [99,100], 低水位99 高水位100
事务 B(101) 数组: [99,100,101], 低水位99 ,高水位102
事务 C(102) 数组: [99,100,101,102]. 低水位99.高水位102

A事务(100) 数组: [99,100]:
虽然最先开始,但是做了其他的事,最后来读取这行
查询语句的读数据流程是这样的：

找到最新的 (1,3) 的时候， row trx_id=101，比高水位100大，不可见；
undo log 往前找，找到上一个历史版本，一看 row trx_id=102，比高水位100大，不可见；
undo log 往前找,找到了（1,1)，它的 row trx_id=90，比低水位99小，处于绿色区域，可见
A事务(100) 什么时候读都是(1,1),看到这行数据的结果都是一致的，所以我们称之为一致性读。

当前读

更新数据, 不能再读视图的数据来更新了, 不然就不对了, 因此只能读当前的值，称为“当前读”（current read）
当前读: 必须读最新版本, 如果最新版本的另一个事务没提交, 本事务只能堵塞 等他提交 再接着执行, 并且对自己读到的数据加锁 不让其他事务改
select...lock in share mode ,(共享锁)
select...for update(排他锁)
update , delete , insert(排他锁)
这些都是当前读,就是加锁, 会阻塞

事务B(101),如果在更新之前插一句读取此行的数据 会读到1, 因为事务c(102)的修改对它不可见,
但是事务B(101) 的+1修改, 必须基于最新的数据(1,2), 不然就丢失事务c(102)的更新了

更新的过程,包括当前读current read

更新数据都是先读后写的，而这个读，只能读当前的值，称为“当前读”（current read）。

select 语句如果加锁，也是当前读
事务 A (100)的查询语句 select * from t where id=1 修改一下，加上
lock in share mode :读锁（S 锁，共享锁）
mysql> select k from t where id=1 lock in share mode;
for update:写锁（X 锁，排他锁）
mysql> select k from t where id=1 for update;
也都可以读到版本号是 101 的数据，返回的 k 的值是 3。

事务 B (101),查询时，一看自己的版本号是 101，最新数据的版本号也是 101，是自己的更新，可以直接使用，所以查询得到的 k 的值是 3。

行锁

如果上面事务C 改成 update后不马上commit, 在事务B update后 事务C 才commit

事务 C’没提交，也就是说 (1,2) 这个版本上的写锁还没释放。而事务 B 是当前读(更新)，必须要读最新版本，而且必须加锁，因此就被锁住了，必须等到事务 C’释放这个锁，才能继续它的当前读。

锁等待

读提交情况下

每一个语句执行前都会重新算出一个新的视图。
"start transaction with consistent snapshot; " 无效, 只相当于start transaction开始事务

事务 A .查询语句的视图数组 执行这个语句的时候创建的，时序上 (1,2)、(1,3) 的生成时间都在创建这个视图数组的时刻之前。但是：

(1,3) 还没提交，属于情况 1，不可见；
(1,2) 提交了，属于情况 3，可见。
所以，这时候事务 A 查询语句返回的是 k=2。

事务 B 查询结果 k=3( 自己改的)