1 Replication overview
MySQL supports three types of replication: row-based replication and statement-based replication. Statement-based replication is also called logical replication. Both of these replication methods achieve asynchronous data replication by recording binary logs on the primary database and replaying them on the standby database.
MySQL 的从库（也称为备库或副本）在以下情况下会触发多线程运行机制：
当从库使用多线程复制功能时。MySQL 5.6 版本引入了多线程复制功能，它允许从库使用多个线程并行地复制来自主库的不同数据块。通过使用多线程复制功能，可以提高从库的复制效率。在这种情况下，从库将使用多个 IO 线程和 SQL 线程来处理不同的复制任务。
当从库启用并行复制功能时。并行复制功能是 MySQL 5.7 版本中引入的功能，它允许从库同时处理多个事务。在这种情况下，从库将使用多个 worker 线程来处理并发的复制任务，从而提高复制效率。
无论是多线程复制功能还是并行复制功能，都可以提高从库的复制效率，但需要注意的是，在某些情况下，使用多线程复制功能可能会导致复制延迟增加。因此，在启用多线程复制功能时，需要进行适当的配置和监控，以确保其正常运行。
2 working principle
1）在主库上记录二进制日志，在每次准备提交事务完成数据更新前，主库数据将更新二进制日之前，mysql会根据提交的顺序而非执行顺序记录二进制日志。在记录二进制日之后主库会告诉存储引擎可以提交事务了
2）备库将主库的二进制日志复制到本地的中继日志中，首先，备库会启动一个工作线程（i/o线程），io线程和主库线程建立一个普通的客户端连接，然后再主库上启动一个特殊的二进制转储（binlog dump）线程，这个二进制转储线程会读取主库二进制日志中的事件，但不会对事件进行轮询。如果该线程追上了主库，他将进入睡眠状态。直到主库发送信号量通知其有新的事件产生时才会被唤醒，备库的io线程会将收到的事件记录到中继日志中
3）备库的sql线程从中继日志中读取事件并在从库上执行，从而实现备库的数据更新，当sql线程赶上io线程时，中继日志通常已经在系统缓存中，所以中继日志开销很低
Lock contention caused by innodb lock read
正常情况下，innodb的读操作是非阻塞的，但在某些情况下需要加锁。特别是在使用基于语句的复制时，执行insert into xxx select 操作会锁定源表上的所有行，mysql通过加锁确保执行结果在主库和从库上是一致的（加锁导致在主库上的语句串行化，以确保备库上以相同方式执行）
解决方法：
1）把大命令拆分成小命令
2）现在主库上执行select into outfile再执行load data infile
Cause of delay from library
1）因为mysql是单线程复制，所以备库只会有效的利1个cpu和磁盘
2）其他在备库上运行的查询可能会阻塞复制线程，因为复制时单线程的，单线程在等待时没法做别的事情
3）复制的两种延时方式：
突然产生延时，再跟上：由于一条很长的查询导致的
稳定的延时增大：看资源占用情况
4）备库上中继日志满了
5）长事物导致延迟时间波动：如果有一个更新数据的事物持续运行1小时，然后才提交，则更新将在实际更新发生1小时后才写入二进制日志，不笨处理语句时，会显示一小时的延迟，然后再突然调回延迟0秒
multithreaded copy
There are two modes of multi-thread replication
1) database: You can use multi-thread to update different databases, but you will not use two threads to follow the same database at the same time. If the data is distributed in multiple databases of mysql, you can simultaneously and Consistently update them, high efficiency
2) logical_clock: Allows parallel updates to a database, as long as they are part of the same binary log commit