文章目录

前言表定义自增值idInnoDB系统自增row_idXidInnodb

trx_id

InnoDB数据可见性的核心思想为什么要加248为何只读事务不分配trx_idthread_id

MySQL的自增id都定义了初始值然后不断加步长。

虽然自然数没有上限但定义了表示这个数的字节长度计算机存储就有上限。

比如无符号整型(unsigned

表定义自增值id

表定义的自增值达到上限后的逻辑是再申请下一个id时得到的值保持不变。

mysql

------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

Table

------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

CREATE

------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

row

t.PRIMARY第一个insert成功后该表的AUTO_INCREMENT还是4294967295导致第二个insert又拿到相同自增id值再试图执行插入语句主键冲突。

2^32

14294967295不是一个特别大的数一个频繁插入删除数据的表是可能用完的。

建表时就需要考虑你的表是否有可能达到该上限若有就应创建成8字节的bigint

InnoDB系统自增row_id

若你创建的InnoDB表未指定主键则InnoDB会自动创建一个不可见的6个字节的row_id。

InnoDB维护了一个全局的dict_sys-row_id值

所有无主键的InnoDB表每插入一行数据都将当前的dict_sys-row_id作为要插入数据的row_id然后把dict_sys-row_id加1。

代码实现时row_id是个长度为8字节的无符号长整型(bigint

unsigned)。

但InnoDB在设计时给row_id留的只是6个字节的长度这样写到数据表中时只放了最后6个字节所以row_id能写到数据表中的值就有两个特征

当dict_sys.row_id2^48时如果再有插入数据的行为要来申请row_id拿到以后再取最后6个字节的话就是0

2^48

InnoDB里申请到row_idN后就将这行数据写入表中若表中已经存在row_idN的行新写入的行就会覆盖原有的行。

验证该结论通过gdb修改系统的自增row_id。

用gdb是为了便于复现问题只能在测试环境使用。

可见在我用gdb将dict_sys.row_id设置为2^48之后再插入a2会出现在表t的第一行因为该值的row_id0。

之后再插入a3由于row_id1就覆盖了之前a1的行因为a1这一行的row_id也是1。

所以应该在InnoDB表中主动创建自增主键当表自增id到达上限后再插入数据时会报主键冲突错误。

毕竟覆盖数据就意味着数据丢失影响数据可靠性报主键冲突插入失败影响可用性。

一般可靠性优于可用性。

Xid

log和binlog有个共同字段Xid用来对应事务。

Xid在MySQL内部是如何生成的呢

MySQL内部维护了一个全局变量global_query_id

若当前语句是该事务执行的第一条语句则MySQL还会同时把query_id赋值给该事务的Xid

而global_query_id是一个纯内存变量重启之后就清零了。

所以同一DB实例不同事务的Xid可能相同。

但MySQL重启之后会重新生成新binlog文件这就保证同一个binlog文件里的Xid唯一。

虽然MySQL重启不会导致同一个binlog里面出现两个相同Xid但若global_query_id达到上限就会继续从0开始计数。

理论上还是会出现同一个binlog里面出现相同Xid。

执行一个事务假设Xid是A接下来执行2^64次查询语句让global_query_id回到A

2^64太大了这种可能只存在于理论中。

再启动一个事务这个事务的Xid也是A

Innodb

InnoDB内部使用Xid为了关联InnoDB事务和server

但InnoDB自己的trx_id是另外维护的事务idtransaction

InnoDB内部维护了一个max_trx_id全局变量每次需要申请一个新的trx_id时就获得max_trx_id的当前值然后并将max_trx_id加1。

每一行数据都记录了更新它的trx_id当一个事务读到一行数据时判断该数据是否可见就是通过事务的一致性视图与这行数据的trx_id做对比。

对于正在执行的事务你可以从information_schema.innodb_trx表中看到事务的trx_id。

mysql

--------------------------------------

trx_id

--------------------------------------

421972504382792

--------------------------------------

row

sec)S2从innodb_trx表里查出的这两个字段第二个字段trx_mysql_thread_id就是线程id。

显示线程id是为说明这两次查询看到的事务对应的线程id都是5即S1所在线程。

t2时显示的trx_id是一个很大的数t4时刻显示的trx_id是1289看上去是一个比较正常的数字。

这是为啥

t1时S1还未涉及更新是一个只读事务。

对于只读事务InnoDB并不会分配trx_id

t1时trx_id的值就是0。

而这个很大的数只是显示用直到S1在t3时执行insertInnoDB才真正分配trx_id。

所以t4时S2查到该trx_id的值就是1289。

语句后面加上for

delete语句除了事务本身还涉及到标记删除旧数据即要把数据放到purge队列里等待后续物理删除这个操作也会把max_trx_id1

因此在一个事务中至少加2InnoDB的后台操作比如表的索引信息统计这类操作也是会启动内部事务的因此你可能看到trx_id值并不是按照加1递增的。

每次查询时由系统临时计算

当前事务的trx变量的指针地址转成整数再加上248这样可以保证

innodb_trx还是在innodb_locks表里同一个只读事务查出来的trx_id就会是一样的若有并行只读事务每个事务的trx变量的指针地址肯定不同。

这样不同并发只读事务查出来的trx_id就是不同的。

为什么要加248

保证只读事务显示的trx_id值比较大正常情况下就会区别于读写事务的id。

但trx_id跟row_id的逻辑类似定义为8个字节。

理论上还是可能出现一个读写事务与一个只读事务显示的trx_id相同。

不过概率很低也没有什么实质危害不管。

为何只读事务不分配trx_id

减小事务视图里面活跃事务数组的大小。

因为当前正在运行的只读事务不影响数据的可见性判断。

所以在创建事务的一致性视图时InnoDB就只需要拷贝读写事务的trx_id减少trx_id的申请次数。

InnoDB执行一个普通的select语句也要对应一个只读事务。

所以只读事务优化后普通查询语句无需申请trx_id大大减少并发事务申请trx_id的锁冲突

max_trx_id

会持久化存储重启也不会重置为0。

理论上只要一个MySQL实例跑得够久就可能出现max_trx_id达到2^48

复现脏读

1第二条事务id就是0了这条update执行后生成的数据版本上的trx_id0

t3时

A执行select的可见性判断c3这个数据版本的trx_id0小于事务TA的低水位2^48

由于低水位值会持续增加而事务id从0开始计数导致系统在该时刻后所有查询都会出现脏读。

并且MySQL重启时max_trx_id也不会清0即重启MySQL这个bug仍然存在。

那这bug也是只存在于理论上吗

假设一个MySQL实例的TPS是50w持续这样17.8年后就会出现该情况。

但从MySQL真正开始流行到现在恐怕都还没有实例跑到过这个上限。

不过只要MySQL实例服务时间够长就必然会出现该bug。

thread_id

每新建一个连接就将thread_id_counter赋值给这个新连接的线程变量new_id。

thread_id_counter定义为4个字节因此达到2^32

但不会在show

processlist看到两个相同的thread_id。

因为MySQL使用了一个唯一数组

表的自增id达到上限后再申请时它的值就不会改变进而导致继续插入数据时报主键冲突错误

row_id达到上限后则会归0再重新递增如果出现相同的row_id后写的数据会覆盖之前的数据

Xid只需要不在同一个binlog文件中出现重复值即可。

虽然理论上会出现重复值但是概率极小可以忽略不计

递增值每次MySQL重启都会被保存起来所以我们文章中提到的脏读的例子就是一个必现的bug好在留给我们的时间还很充裕。