无主键表在row模式下触发全表扫描：主库binlog记录每行前镜像，从库sql线程因无法索引定位，须对每行变更执行一次全表扫描，导致同步卡顿；根本解法是添加主键，参数调优仅能有限缓解。
无主键表在ROW模式下触发全表扫描
MySQL主从复制启用binlog_format=ROW时，主库会把被删/改行的完整前镜像（before_image）写入binlog。从库SQL线程必须根据这些字段值，在本地表中逐行比对、定位目标行。如果表没有主键或唯一索引，就无法利用索引快速跳转——只能走TABLE SCAN，也就是对整张表每行都做一次字段匹配。
举个例子：主库一条DELETE FROM t WHERE status = 0 LIMIT 10000影响1万行，binlog里会记录1万个独立的Delete_rows_event。从库就得执行1万次全表扫描，而不是1次扫描+批量标记删除。数据量越大，这种放大效应越致命——1亿行表扫一遍可能耗时数小时。
slave_rows_search_algorithms参数能缓解但不能根治
MySQL 5.6.6起支持slave_rows_search_algorithms参数，控制从库查找行的策略。默认是TABLE_SCAN,INDEX_SCAN；加上HASH_SCAN后，从库会先把当前event里的before_image缓存成哈希表，再用它去匹配表中行，避免重复扫描。
- 只对无索引表有效：有主键或唯一索引时，MySQL自动优先用索引，该参数不起作用
- 内存开销明显：哈希表需加载所有匹配字段的组合，大宽表或大量event并发时易OOM
- 不解决根本问题：仍依赖字段值完全一致匹配，NULL值、字符集隐式转换、浮点精度差异都会导致哈希失配，退化回全表扫描
并行复制（MTS）对此类延迟基本无效
很多人误以为开多线程就能解决——但slave_parallel_type=LOGICAL_CLOCK或DATABASE的并行粒度，取决于事务间的逻辑依赖或库名隔离。而无主键表的单条DML产生的多个binlog event，在逻辑上仍是强顺序依赖的（比如同一行被连续update两次），无法拆给不同worker并发执行。
实测显示：即使设置slave_parallel_workers=32，面对无主键表的批量delete，实际活跃worker常只有1–2个，其余空转等待。因为每个event都得串行完成“哈希构建→全表/哈希匹配→执行”，瓶颈卡在单行定位环节，不是调度问题。
真正有效的解法只有两个方向
加主键是最直接、零成本、无副作用的方案。InnoDB要求每张表有聚簇索引，显式定义PRIMARY KEY后，从库能直接按主键B+树定位，复杂度从O(n)降到O(log n)。哪怕只是id BIGINT UNSIGNED AUTO_INCREMENT PRIMARY KEY也足够。
实在无法加主键（如日志归档表），必须满足以下全部条件才可临时缓解：
- 确保
binlog_row_image=FULL（不能是MINIMAL或NOBLOB） - 设置
slave_rows_search_algorithms='TABLE_SCAN,INDEX_SCAN,HASH_SCAN' - 从库
innodb_buffer_pool_size足够大，避免哈希表频繁刷出内存 - 业务接受
Seconds_Behind_Master偶尔跳升——因为HASH_SCAN本身也会引入额外CPU和内存压力
别指望参数调优能绕过存储引擎的设计约束。无主键表的复制延迟本质是定位能力缺失，不是配置没调够。
