45 | MySQL中主键自增id达到上限？xid也能达到上限？trx_id也也可以到上限？

一、前言

目前MySQL笔记先暂时学到一个段落了，接下来就是继续复习～

二、正文

1.rowid什么时候是非隐式可查询的？内部实现原理是什么？有什么问题？

• 当有主键、唯一键时

• 如果InnoDB 表没有指定主键，那么 InnoDB 会给你创建一个不可见的，长度为 6 个字节的 row_id。InnoDB 维护了一个全局的 dict_sys.row_id 值，所有无主键的 InnoDB 表，每插入一行数据，都将当前的 dict_sys.row_id 值作为要插入数据的 row_id，然后把 dict_sys.row_id 的值加 1。

• 当不设置主键时，大家都用这个全局唯一id，当id达到上限时就会产生覆盖，因为如果再有插入数据的行为要来申请 row_id，拿到以后再取最后 6 个字节的话就是 0。

2.xid是什么，为什么存在？内部实现原理是什么？重启后会出现相同的xid么，为什么？有什么特殊情况会导致同一个binlog文件中出现两个一样的xid？

• 为了记录redo log和binlog事务之间的关联关系

• 内部是由一个全局的变量 global_query_id（纯内存变量），每次执行语句的时候将它赋值给 Query_id，然后给这个变量加 1。如果当前语句是这个事务执行的第一条语句，那么 MySQL 还会同时把 Query_id 赋值给这个事务的 xid。

• 不会，MySQL 重启之后会重新生成新的 binlog 文件，这就保证了，同一个 binlog 文件里，Xid 一定是惟一的。

• 执行一个事务，假设 xid 是 A；接下来执行 2的64次方查询语句，让 global_query_id 回到 A；再启动一个事务，这个事务的 xid 也是 A。

3.trx_id是什么？内部实现原理是什么？会持久化？如何查询一个事物的trx_id？非只读事务一次只会加一？只读事务id会分配trx_id么，分配算法是什么？为什么用这个算法？只读事务不会分配trx_id的好处是什么？一旦trx_id到达上限那么会如何？

• 主要是用来体现事务一致性视图，即：可见性判定

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

• 会

• use information_schema; select trx_id, trx_mysql_thread_id from innodb_trx;

• 是的，但是你看到的不一定是加一。因为：1）update 和 delete 语句除了事务本身，还涉及到标记删除旧数据，也就是要把数据放到 purge 队列里等待后续物理删除，这个操作也会把 max_trx_id+1， 因此在一个事务中至少加 2；2）InnoDB 的后台操作，比如表的索引信息统计这类操作，也是会启动内部事务。

• 只读事务，InnoDB 并不会分配 trx_id。算法是：把当前事务的 trx 变量的指针地址转成整数，再加上 2的48次方。

• 同一个只读事务在执行期间，它的指针地址是不会变的，所以不论是在 innodb_trx 还是在 innodb_locks 表里，同一个只读事务查出来的 trx_id 就会是一样的。--为什么加 2的64次方？区别非只读事务，让人一下子就能明显看出来。

• 1）减小了事务的一致性视图大小。2）减少锁竞争。

• 可重复读隔离级别下会出现脏读现象

4.thread_id的分配策略是如何的？

• 系统保存了一个全局变量 thread_id_counter，每新建一个连接，就将 thread_id_counter 赋值给这个新连接的线程变量。内部使用锁自旋原理。