MySql 主从同步会不会影响到SQL执行速度？

异步复制（默认）：
主库在执行完客户端提交的事务后会立即将结果返给客户端，并不关心从库是否已经接受处理 客户端体验好,所以并不会影响到SQL执行速度

全同步复制
放主库执行完一个事物，会等待–(所有从库)–都执行了该事务才返回给客户端

半同步复制
介于异步和同步之间，主库在执行完客户端提交事务后不是立刻返回给客户端，而是等待–(至少一个)–从库接受到并写到relay log 中才返回给客户端
全同步复制

 原文链接：https://blog.csdn.net/m0_45036821/article/details/105933929

主从同步开启的时候，slave上会创建两个线程：I\O线程和Sql线程。
I\O线程连接到master机器，master机器上的binlog dump 线程会将binlog的内容发送给该I\O线程。该I/O线程接收到binlog内容后，再将内容写入到本地的relay log；
sql线程。该线程读取到I/O线程写入的ralay log。并且根据relay log。并且根据relay log 的内容对slave数据库做相应的操作。

总结一下主从同步原理：

主库（Master）线程

Binlog Dump 线程（Binlog Dump Thread）

作用：负责将主库的二进制日志（binary log）数据传输到从库。
工作方式：当从库连接到主库时，主库会为每个连接的从库开启一个 Binlog Dump 线程。这个线程从主库的二进制日志中读取日志记录，并将其发送给从库。

Binlog Dump GTID 线程（Binlog Dump GTID Thread）

作用：处理与 GTID（Global Transaction Identifier）相关的复制任务。
工作方式：在 GTID 模式下，主库会开启一个专门处理 GTID 的线程，以确保 GTID 复制的正确性和一致性。

从库（Slave）线程

I/O 线程（I/O Thread）

作用：负责从主库接收二进制日志并将其写入到从库的中继日志（relay log）。
工作方式：从库的 I/O 线程连接到主库，读取主库的二进制日志，然后将这些日志记录写入到从库的中继日志中。

SQL 线程（SQL Thread）

作用：在从库上执行主库的变更操作。
工作方式：从库的 SQL 线程读取从中继日志中提取的日志记录，并在从库上执行这些记录中的 SQL 语句，从而实现数据同步。

Relay Log Writer 线程（Relay Log Writer Thread）

作用：负责将从主库接收到的二进制日志写入到从库的中继日志。
工作方式：Relay Log Writer 线程从 I/O 线程接收到的日志数据中写入中继日志文件，为 SQL 线程提供执行的输入。

Relay Log Reader 线程（Relay Log Reader Thread）

作用：读取从库的中继日志。
工作方式：Relay Log Reader 线程读取中继日志中的数据，并将其传递给 SQL 线程进行执行。

总结

主库：

Binlog Dump 线程：将二进制日志传输给从库。
Binlog Dump GTID 线程（在启用 GTID 模式时）：处理 GTID 相关的复制任务。

从库：

I/O 线程：从主库接收二进制日志并写入中继日志。
SQL 线程：读取中继日志并执行日志记录中的 SQL 语句。
Relay Log Writer 线程：将二进制日志写入中继日志。
Relay Log Reader 线程：读取中继日志并传递给 SQL 线程。
这些线程在主从复制过程中各司其职，确保主库和从库之间的数据一致性和同步。

什么是GTID模式？

启用 GTID 模式（Global Transaction Identifier）之后，你通常不需要在配置从库时指定 MASTER_LOG_FILE 和 MASTER_LOG_POS 这两个参数。这是因为 GTID 模式提供了更为先进的复制方式，可以自动管理和跟踪事务的状态，无需手动指定日志文件和位置。

GTID 模式的工作原理

GTID 模式 通过全局唯一的事务标识符（GTID）来跟踪和管理事务。这些标识符是全球唯一的，能确保主库和从库之间的一致性。

主库 在 GTID 模式下会为每个事务分配一个唯一的 GTID，并将其记录到二进制日志中。

从库 在同步过程中，通过 GTID 来确定哪些事务已经应用，从而实现与主库的数据一致性。GTID 可以自动处理事务的应用，无需从库知道具体的日志文件和位置。

那么主从同步为什么发生从库同步延迟问题呢？

MySQL 主从复制基本原理

主库写入操作：

当主库（Master）上有写操作（如 DDL 和 DML 操作，即数据定义语言和数据操作语言）时，这些操作会被记录到二进制日志（binlog）中。
Binlog 是顺序写入的，所以效率很高。

从库读取日志：

从库（Slave）有一个 Slave_IO_Running 线程，它的工作是从主库读取 binlog 并存储在自己的中继日志（relay log）中。
这一过程效率较高，因为它主要是顺序读取和写入。

从库应用日志：

从库有一个 Slave_SQL_Running 线程，它从中继日志中读取记录并在从库上执行这些操作。
这些操作在从库上可能是随机写入的，这样会导致更多的 I/O 操作和潜在的锁竞争，成本比顺序写高很多。

为什么从库会有延迟

单线程限制：

Slave_SQL_Running 线程是单线程的，这意味着从库在执行 DDL 和 DML 操作时是顺序执行的。如果一个操作（比如一个耗时10分钟的 DDL 操作）阻塞了，那么所有后续的操作都要等它完成后才能执行。

主库并发执行：

主库可以并发地执行多个操作，因此即使一个操作需要10分钟，其它操作也可以继续执行，不会阻塞。而从库由于单线程的限制，会导致操作被顺序阻塞，从而产生延迟。也就是当主库的TPS并发较高时，产生的DDL数量超过slave一个sql线程所能承受的范围，那么延时就产生了

主从数据不同步的解决方案是什么？

主从数据库开启后可能出现什么问题

1. 主库宕机后，数据可能丢失
2. 从库只有一个sql Thread，主库写压力大，复制很可能延时

解决方案

1. 半同步复制mysql semi-sync解决数据丢失的问题
2. 并行复制解决从库复制延迟的问题

异步复制原理、半同步复制和并行复制原理比较

事务在主库写完binlog后需要从库返回一个已接受，才放回给客户端；5.5集成到mysql，以插件的形式存在，需要单独安装确保事务提交后binlog至少传输到一个从库不保证从库应用完成这个事务的binlog性能有一定的降低网络异常或从库宕机，卡主库，直到超时或从库恢复