每日一个MySQL问题: MTS 高并发下主从表空间不一致的问题

简单记录原因，最近我也遇到这样的问题，涉及的知识点其实很多，我也仅仅是简单分析了一下，供参考。模拟版本8.0.28。

---

一、问题说明和模拟方式

就是主从一个表，主库大约600M，从库大约900M，当然主从的环境肯定是一致的，但是从库的并发比较高MTS使用了16个 worker线程，从并发来看基本都在使用。

我模拟的方法也很简单，无非就是主库开启writeset，将参数binlog_transaction_dependency_history_size调大，这样能够保证last commit尽可能降低，如下：

mysql> set global binlog_transaction_dependency_history_size=1000000;
mysql> set global binlog_transaction_dependency_tracking='writeset';
表结构
mysql> show create table mytestpri  \G
*************************** 1. row ***************************
       Table: mytestpri
Create Table: CREATE TABLE `mytestpri` (
  `id` int NOT NULL AUTO_INCREMENT,
  `name` varchar(20) COLLATE utf8mb4_general_ci DEFAULT NULL,
  PRIMARY KEY (`id`)
) ENGINE=InnoDB AUTO_INCREMENT=2337812 DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_general_ci
1 row in set (0.01 sec)

然后循环每次插入100行数据。使用语句
insert into mytestpri(name) select name from mytestpri limit 100;

这样生成的binlog的last commit大概如下：

反正就是很多相同的可以在从库并发执行。这样达到的目的就是主库看起来是连续插入的，因为是自增，但是到了从库并发下则不是连续的，是可以并发的，那么比如990-1000这个数据可能在1000-1010之后才插入，虽然提交是考虑了顺序的（slave_preserve_commit_order=ON），但是执行并没有顺序