MySql 主从同步会不会影响到SQL实行速率？

异步复制（默认）：
主库在实行完客户端提交的事务后会立即将结果返给客户端，并不关心从库是否已经接受处理 客户端体验好,所以并不会影响到SQL实行速率
全同步复制
放主库实行完一个事物，会等待–(全部从库)–都实行了该事务才返回给客户端
半同步复制
介于异步和同步之间，主库在实行完客户端提交事务后不是立刻返回给客户端，而是等待–(至少一个)–从库接受到并写到relay log 中才返回给客户端
全同步复制

1. 原文链接：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线程所能承受的范围，那么延时就产生了
主从数据差别步的办理方案是什么？

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

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

办理方案

• 半同步复制mysql semi-sync办理数据丢失的题目
  
• 并行复制办理从库复制延迟的题目
  

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

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

免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！更多信息从访问主页：qidao123.com:ToB企服之家，中国第一个企服评测及商务社交产业平台。