为什么要加248？
保证只读事务显示的trx_id值比较大，正常情况下就会区别于读写事务的id。但trx_id跟row_id的逻辑类似，定义为8个字节。
理论上还是可能出现一个读写事务与一个只读事务显示的trx_id相同。不过概率很低，也没有什么实质危害，不管。
为何只读事务不分配trx_id？
- 减小事务视图里面活跃事务数组的大小。因为当前正在运行的只读事务，不影响数据的可见性判断。所以，在创建事务的一致性视图时，InnoDB就只需要拷贝读写事务的trx_id
- 减少trx_id的申请次数。InnoDB执行一个普通的select语句，也要对应一个只读事务。所以只读事务优化后，普通查询语句无需申请trx_id，大大减少并发事务申请trx_id的锁冲突
由于只读事务不分配trx_id，显然trx_id的增速变慢。
但 max_trx_id 会持久化存储，重启也不会重置为0。理论上，只要一个MySQL实例跑得够久，就可能出现max_trx_id达到2^48 - 1，然后从0开始循环。
达到该状态后，MySQL就会持续出现一个脏读bug：
首先把当前的max_trx_id先修改成2^48 - 1。这里是可重复读。
- 复现脏读
因为系统的max_trx_id被设置成2^48 - 1，所以在session A启动的事务TA的低水位就是2^48 - 1。
t2时:
- session B执行第一条update语句的
事务id=2^48 - 1 - 第二条事务id就是0了，这条update执行后生成的数据版本上的
trx_id=0
t3时：
session A执行select的可见性判断：c=3这个数据版本的trx_id（0），小于事务TA的低水位（2^48 - 1），所以认为该数据可见。
但这是脏读。
由于低水位值会持续增加，而事务id从0开始计数，导致系统在该时刻后，所有查询都会出现脏读。
并且MySQL重启时max_trx_id也不会清0，即重启MySQL，这个bug仍然存在。那这bug也是只存在于理论上吗？
假设一个MySQL实例的TPS是50w，持续这样，17.8年后就会出现该情况。但从MySQL真正开始流行到现在，恐怕都还没有实例跑到过这个上限。不过，只要MySQL实例服务时间够长，就必然会出现该bug。
这也可以加深对低水位和数据可见性的理解。
thread_id
系统保存了一个全局变量thread_id_counter
每新建一个连接，就将thread_id_counter赋值给这个新连接的线程变量new_id。
thread_id_counter定义为4个字节，因此达到2^32 - 1，就会重置为0，继续增加。
但不会在show processlist看到两个相同的thread_id。因为MySQL使用了一个唯一数组
给新线程分配thread_id时的逻辑：
总结
每种自增id有各自的应用场景，在达到上限后的表现也不同：
- 表的自增id达到上限后，再申请时它的值就不会改变，进而导致继续插入数据时报主键冲突错误
- row_id达到上限后，则会归0再重新递增，如果出现相同的row_id，后写的数据会覆盖之前的数据
- Xid只需要不在同一个binlog文件中出现重复值即可。虽然理论上会出现重复值，但是概率极小，可以忽略不计
- InnoDB的max_trx_id 递增值每次MySQL重启都会被保存起来，所以我们文章中提到的脏读的例子就是一个必现的bug，好在留给我们的时间还很充裕
