trx_id是Innodb中标识一个事务的id，是一个6字节长度的整数。这个id的值来源于Innodb维护的max_trx_id,当需要申请一个新的trx_id值时，就获取max_trx_id的最新值，然后将max_trx_id值加1。
注：max_trx_id和row_id类似，存储时使用数据类型是8字节，但是只使用其后6字节数据，当max_trx_id超过了2的48次方时，max_trx_id的值，有会从0开始循环。关于mysql中其他的自增id介绍，可以参考mysql中的自增id超出上限的问题
对于trx_id的介绍，我们分以下3部分。
1.trx_id是什么时候获取的？
通过上文我们知道，trx_id的值是max_trx_id的当前值。事务通常是在先执行读写语句的时候才会启动。具体如下图：
t2时刻 trx_id的值为空。
t3时刻 trx_id的值为 281475252293752。
t4时刻 trx_id的值为 48245。
这里有一个奇怪的现象，一个事务有两个不同的trx_id， 而且第一个是一个比较大的值，第二个是一个相对较小的值？
出现这个现象的原因，主要是因为Innodb的一个优化：max_trx_id只会给更新事务分配trx_id。
因为在t2时刻，事务中没有涉及到更新操作，此时的事务只是一个只读事务，因为只读事务不会对数据产生任何影响，事务id也没有太大的意义。所以对于只读事务id的分配，不会使用max_trx_id的值，也不会使max_trx_id的值自增。而这个很大的trx_id，是innodb使用当前事务的trx变量的地址转换成整数，然后在加上2的48次方计算得来的。这种计算方式，计算出来的trx_id值会比较大，刚好可以和更新事务做区分，同时不同的事务trx变量的地址值也是不同的，所以只读事务trx_id一般情况下，也是不会相同。
这种优化方案，可以减少trx_id申请的次数，所以max_trx_id增加的速度也就变慢了，同时也减少了trx_id申请过程中锁冲突的几率。
2.trx_id有什么用
在Innodb中数据可见性的核心思想就是，每一行数据都记录着对其进行更新操作的事务id。当一个查询读到一行数据的时候，判断这个数据可见性的逻辑就是通过事务的一致性视图与这行数据的trx_id做对比。以可重复读事务隔离级别为例，事务可见性规则如下：
在可重复读的事务隔离级别下，为了实现数据的可见性，在一个事务启动的时刻，会为这个事务创建一个事务数组，这个数组存放了这个事务启动那一时刻，系统中活跃的所有事务，这里活跃可以理解成已经启动，单未提交的事务，其中数组中trx_id最小的那个事务，被称为低水位线，当前系统中已经创建的事务id的最大值加1记为高水位，具体如下图：
其中中间的黄色部分，就是当前事务创建的事务数组。绿色部分为trx_id小于低水位线且已经提交的事务。而红色部分，表示trx_id高于高水位线的事务，也就是对于当前事务来说的未来事务。
其中，绿色部分和红色部分都比较好理解，而对于黄色部分，还需要额外在多说一点，trx_id大于低水位线，且未提交的事务，存放在黄色部分，这个没什么好说的，但是需要注意的是，“晚启动的事务不一定晚提交”，所以可能存在一些事务，他们的trx_id大于低水位线，小于高水位线，但是已经提交了，其实这部分事务从数值上来说，应该属于黄色部分。
在innodb中判断数据可见性时，有以下规则：绿色部分的事务可见，红色部分的数据不可见，黄色部分中的数据，如果已经提交了，可见，未提交的话，则不可见。
3.trx_id越界了怎么处理
上文提到，如果max_trx_id的值超过了2的48次方后，会重新从0开始循环。根据可重复读事务隔离级别下，事务可见性规则，事务id从0开始循环后，新的事务id会小于当前事务视图的低水位线，也就是本来属于红色区域部分的事务，结果落到了绿色部分。导致当前视图可以看到"未来"事务的更新，也就破坏了上图中，红色区域事务不可见的规则。也就出现了脏读的问题。
不幸的是，mysql并没有对这个问题进行修复。虽然当max_trx_id达到上限后，对mysql影响很严重，但是，要到达这个上限也很难，这个问题通常也只有理论上会发生。