关键字
innodb version 5.7 replication delay
参考&引用
- MySQL Docs: slave_rows_search_algorithms
- slave-performance-too-slow-with-row-based-events-causes-and-workarounds
问题描述
业务表没有主键(唯一键), 主库执行了一条大量删除的DELETE语句导致，导致Slave延时。
表结构设计
由于binlog 是基于Row模式的，主库的一条大量删除DELETE语句会产生大量binlog日志。这种情况下,从库 SQL Thread 在重放Relay Log时，由于表结构不存在唯一键（没有好的索引），导致所有重放都是一次全表扫描。
从设计上讲，所有表都应该有唯一主键，至少有自增主键（最好强制要求所有表均有自增主键）。这次的问题主要是项目引用的开源的项目（XXX）, 表结构设计的非常有问题。
问题解决
表结构补上唯一索引（或加上自增主键）是最好的方式。 但是如果因为一些原因，无法改表结构的情况，可以临时通过调整slave_rows_search_algorithms参数为INDEX_SCAN,HASH_SCAN(默认值INDEX_SCAN,TABLE_SCAN)，改变从库复制表搜索算法，来加速复制。
--动态参数
set global slave_rows_search_algorithms = 'INDEX_SCAN,HASH_SCAN';
官方文档说明：
* The default value is INDEX_SCAN,TABLE_SCAN, which means that all searches that can use indexes do use them, and searches without any indexes use table scans.
* To use hashing for any searches that do not use a primary or unique key, set INDEX_SCAN,HASH_SCAN. Specifying INDEX_SCAN,HASH_SCAN has the same effect as specifying INDEX_SCAN,TABLE_SCAN,HASH_SCAN, which is allowed.
对照测试实验
同一从库上堆积一个大事务情况下,相同的Exec_Master_Log_Pos,相同时间内,先后观察innodb undo 数相差10倍+（数值仅参考）。
INDEX_SCAN,TABLE_SCAN
INDEX_SCAN,HASH_SCAN
