事务ID

给事务分配id 的时机

一个事务可以是一个只读事务，或者是一个读写事务

只读事务

我们可以通过 START TRANSACTION READ ONLY 语句开启一个只读事务。
在只读事务中不可以对普通的表（其他事务也能访问到的表）进行增、删、改操作，但可以对用户临时表做增、删、改操作。

读写事务

我们可以通过 START TRANSACTION READ WRITE 语句开启一个读写事务，或者使用 BEGIN、START TRANSACTION 语句开启的事务默认也算是读写事务。
在读写事务中可以对表执行增删改查操作。

事务ID分配

如果某个事务执行过程中对某个表执行了增、删、改操作，那么 InnoDB 存储引擎就会给它分配一个独一无二的事务 **id，分配方式如下：
对于只读事务来说，只有在它第一次对某个用户创建的临时表执行增、删、改操作时才会为这个事务分配一个事务 id，否则的话是不分配事务 id 的。
我们前边说过对某个查询语句执行 EXPLAIN 分析它的查询计划时，有时候在Extra 列会看到 Using temporary 的提示，这个表明在执行该查询语句时会用到内部临时表。这个所谓的内部临时表和我们手动用 CREATE TEMPORARY TABLE 创建的用户临时表并不一样，在事务回滚时并不需要把执行 SELECT 语句过程中用到的内部临时表也回滚，在执行 SELECT 语句用到内部临时表时并不会为它分配事务 id。
对于读写事务来说，只有在它第一次对某个表（包括用户创建的临时表）执行增、删、改操作**时才会为这个事务分配一个事务 id，否则的话也是不分配事务id 的。
有的时候虽然我们开启了一个读写事务，但是在这个事务中全是查询语句， 并没有执行增、删、改的语句，那也就意味着这个事务并不会被分配一个事务 id。
上边描述的事务 id 分配策略是针对 MySQL 5.7 来说的，前边的版本的分配方式可能不同。

事务id 生成机制

这个事务 id 本质上就是一个数字，它的分配策略和我们前边提到的对隐藏列 row_id（当用户没有为表创建主键和 UNIQUE 键时 InnoDB 自动创建的列）的分配策略大抵相同，具体策略如下：
服务器会在内存中维护一个全局变量，每当需要为某个事务分配一个事务 id时，就会把该变量的值当作事务 id 分配给该事务，并且把该变量自增 1。
每当这个变量的值为 256 的倍数时，就会将该变量的值刷新到系统表空间的页号为 5 的页面中一个称之为 Max Trx ID 的属性处，这个属性占用 8 个字节的存储空间。
当系统下一次重新启动时，会将上边提到的 Max Trx ID 属性加载到内存中， 将该值加上 256 之后赋值给我们前边提到的全局变量（因为在上次关机时该全局变量的值可能大于 Max Trx ID 属性值）。
这样就可以保证整个系统中分配的事务 id 值是一个递增的数字。先被分配id 的事务得到的是较小的事务 id，后被分配 id 的事务得到的是较大的事务 id。

trx_id 隐藏列

聚簇索引的记录除了会保存完整的用户数据以外，而且还会自动添加名为 trx_id、roll_pointer 的隐藏列， 如果用户没有在表中定义主键以及 UNIQUE 键，还会自动添加一个名为 row_id 的隐藏列。其中的 trx_id 列就是某个对这个聚簇索引记录做改动的语句所在的事务对应的事务 id