一：前言
- 前面通过 《Mysql 事务 - 隔离》 的学习，知道了事务的实现，是根据 获取一致性视图 来实现的。
二：那么，什么时候会获取到一致性视图呢？
- 例如：有三个事务，启动的详情如图（autocommit = 1）
- 
- 事务 A,B,C 查到的值是多少呢？
- 事务 B 查到的 k 的值是 3，而事务 A 查到的 k 的值是 1
- 理解
- begin/start transaction 命令并不是一个事务的起点，在执行到它们之后的第一个操作 InnoDB 表的语句，事务才真正启动。
三：一致性视图的实现？
- 在可重复读隔离级别下，事务在启动的时候就“拍了个快照”。注意，这个快照是基于整库的。
- 这时，你会说这看上去不太现实啊。如果一个库有 100G，那么我启动一个事务，MySQL 就要拷贝 100G 的数据出来，这个过程得多慢啊。可是，我平时的事务执行起来很快啊。
- 这就引入了 InnoDB 的 MVCC 概念。
四：多版本并发控制（MVCC）
- 概念
- Mysql 的大多数事务存储引擎实现的都不是简单的行级锁，一般都实现了 MVVC（多版本并发控制）
- 不同的引擎对于MVCC的实现不同，典型的有（乐观并发控制/悲观并发控制）
- 原理
- 通过保存数据在某点的快照实现，也是就说，不过执行多长时间,每个事务看到的数据都是一致的。
- 也就是说，事务的开始时间不同，对于同一张表，同一时刻看的的数据可能是不同的。
- 详解
- 通过在每行记录后面保存两个隐藏列实现
- 一个保存的行的创建时间
- 一个保存行的过期时间
- 时间保存的并不是实际的时间
- 而是系统的版本号，每开始一个新事务，版本号会自动递增
- 事务开始时刻的系统版本号会作为事务的版本号，用来和查询到的每行记录的版本号作为比较
- MVVC 流程 - 以 REPEATTABLE READ （可重复读 - 隔离级别）举例
- SELECT
- InnoDB 只会查找版本早于当前事务版本的数据行，可以保证事务读取的行
- 要么是在事务开始前已经存在的。
- 要么是在事务自身插入或者修改过的。
- 行的删除版本要么未定义，要么大与当前事务版本号这样可以确保事务读取到的行，在事务开始未被删除。
- INSERT
- 为新插入的一行保存当前的系统版本号作为行版本号。
- DELETE
- 为删除的一行保存当前的系统版本号作为行删除标识
- UPDATE
- 新插入一行记录，保存当前系统版本号作为行版本号。
- 同时保存当前系统的版本号到原来的行，作为行删除标识。
- 注意点
- 保存着两个版本号，使得大多数的读操作都不需要加锁。
- 这样的设计使得读数据更简单，性能很好，并且也能保证只会读到符合标准的行。
- 不足是每行记录都需要额外的存储空间，需要做更多的维护工作。
- 目前 MVVC 只工作在 读已提交/可重复读 两个隔离级别下
- 读未提交 总会读取最新的行
- 串行化则会对所有读取到的行加锁。
五：附录
-
* mysql> show table status like 'tblwechatTemplate' \G; * *************************** 1. row *************************** * Name: tblwechatTemplate * 表名 * Engine: InnoDB * 引擎 * Version: 10 * Row_format: Dynamic * 行模式 * Rows: 32 * 表中的行数 * 对于 MyIsam 和其他是准确的 * 对于 InnoDB 是估计值 * Avg_row_length: 2048 * 平均每行包含的字节 * Data_length: 65536 * 表数据的大小 * Max_data_length: 0 * 表数据的最大容量，和存储引擎有关 * Index_length: 49152 * 索引大小（字节） * Data_free: 0 * Auto_increment: 35 * 下个自增主键的值 * Create_time: 2019-04-22 16:19:21 * 表创建时间 * Update_time: 2019-05-16 17:03:45 * 表数据最后修改时间 * Check_time: NULL * Collation: utf8_general_ci * 默认字符集和排序规则 * Checksum: NULL * Create_options: * Comment: 模板消息模板id记录表