![mysql无主键无索引表导致同步延迟,第1张 mysql无主键无索引表导致同步延迟,第1张](/aiimages/mysql%E6%97%A0%E4%B8%BB%E9%94%AE%E6%97%A0%E7%B4%A2%E5%BC%95%E8%A1%A8%E5%AF%BC%E8%87%B4%E5%90%8C%E6%AD%A5%E5%BB%B6%E8%BF%9F.png)
Mysql主从同步延迟发生 现象: pos一直保持不变,并且behind一直在增加, 备库执行: SQL thread State列状态如下: 代表 线程已经从中继日志读取一个事件,可以对事件进行处理了。 查看binlog: 查看表结构发现没有
主键和
索引。 延迟发生原因: 首先mysql主从是基于行的复制。 举例解释下什么是基于行的复制,假设主库执行以下sql删除了表A中的100条
数据: 这时mysql会把这个SQL按照每条记录,拆分成100条delete SQL在备库上执行,mysql这么做的目的也是最大程度的保证同步数据的可靠性。 但是可靠性的提升伴随而来的便是日志量的增多,同步过程会占用大量带宽。 其次,该表即无主键,也没有索引。 假设还是以上对A表的删除 *** 作,拆成的100条delete SQL传递并且在备库执行,因为表即无主键,也没有索引,所以每执行一次都要做全表扫描才能定位到要删除的那一条数据,可想而知同步效率会低很多。 解决方案: 1 表设计时就要有主键; 2 如果延迟已经发生,并且表不是特别大的情况下,在备库上为该表创建索引或是主键。1. 在有主键或者唯一键的情况下,Slave 重放 Binlog 并不会去比较检索到的记录的每一列是否和BI相同,因此如果 Slave 和 Master 存在数据不一致,会直接覆盖 Slave 的数据而不会报错。
2. 在没有主键或者唯一键的情况下,Hash Scan / Hash Scan Over Index 的执行效率 在理论上分析高于 Table Scan 和Index Scan 。
3. 在没有主键或者唯一键的情况下,Slave 选择的二级索引是第一个所有的列都在 BI 中存在的索引,不一定是 Master 执行计划所选择的索引。
在同步的时候,重复插入了唯一主键。 e_syslog有了133的值。
你可以 set global sql_slave_skip_counter=1
slave start跳过这步。
评论列表(0条)