mysql无主键无索引表导致同步延迟

Mysql主从同步延迟发生 现象： pos一直保持不变，并且behind一直在增加， 备库执行： SQL thread State列状态如下： 代表 线程已经从中继日志读取一个事件，可以对事件进行处理了。 查看binlog： 查看表结构发现没有主键和索引。 延迟发生原因： 首先mysql主从是基于行的复制。 举例解释下什么是基于行的复制，假设主库执行以下sql删除了表A中的100条数据： 这时mysql会把这个SQL按照每条记录，拆分成100条delete SQL在备库上执行，mysql这么做的目的也是最大程度的保证同步数据的可靠性。 但是可靠性的提升伴随而来的便是日志量的增多，同步过程会占用大量带宽。 其次，该表即无主键，也没有索引。 假设还是以上对A表的删除 *** 作，拆成的100条delete SQL传递并且在备库执行，因为表即无主键，也没有索引，所以每执行一次都要做全表扫描才能定位到要删除的那一条数据，可想而知同步效率会低很多。 解决方案： 1 表设计时就要有主键； 2 如果延迟已经发生，并且表不是特别大的情况下，在备库上为该表创建索引或是主键。

MySQL 默认的复制就是异步的，主库再执行完客户端提交的事务后会立即将结果返回给客户端，并不关系从库是否已经接收和处理。

MySQL主库将Binlog事件写入到Binlog文件中，此时主库只通知一下Dump线程发送这些新的Binlog，然后主库继续处理提交 *** 作，不会保证这些Binlog传到任何一个从库节点上。

因为异步复制，主节点不关从节点是否收到Binlog，如果主crash掉了，此时主节点上已提交的事务可能并没有传到从库上，如果此时，强行将从节点提升为主节点，可能导致新的主节点上数据不完整。

全同步是指当主库接收到客户端的一个事务请求，所有的从库都执行了该事务才返回给客户端。

当主库收到客户端提交的事务后，所有的从库必须收到并且执行事务，然后主库才会执行后续 *** 作。

因为要等待所有从库执行完事务，主库才将结果返回给客户端，所以全同步复制的性能必然受到严重影响，即完成一个事务的时间被拉长，性能降低。

半同步复制是介于全同步复制和全异步复制之间的一种，主库只需要等待至少一个从库节点收到并Flush Binlog到Relay log文件即可，主库不需要等待所有从库给主库反馈。（注意只要收到一个从库的反馈即可）

介于异步复制和全同步复制之间，主库再执行完客户端提交的食物后不是立刻返回给客户端，而是等待至少一个从库接收到并写到relay log中才返回给客户端。

相对于异步复制，半同步复制提交了数据的安全性，同时它也造成了一定程序的延迟，这个延迟至少是一个TCP/IP往返时间，因此，半同步复制虽好在低延时的网络中使用。

XMind - Trial Version

---