背景

    客户Mysql 8.0 主从环境由于历史原因，存在部分大表没有任何主键和唯一索引的情况，此时主库对这种大表的大事务（说白了就批量更新）操作，主库可能影响不大，但主库因binlog为ROW模式，从库在复制时，会进行逐条更新，可怕的全表扫描，从库延迟不可预估，需要进行应急处理。
    此时从库同步只能说在延迟，与异常中断情况还不一样，下面针对这种情况设计几种处理方案，仅供参考。
    注：客户主从采用事务跳过方式修复。

方案设计

    下面将从业务亲和性，实施复杂度，主从可用性，后续影响四个方面对方案进行介绍。

方案一 、添加主键、唯一索引

• 业务亲和性
  需要与业务人员进行确认，在现有表的字段中是否有可以作为主键或者唯一索引的列，可能涉及到业务逻辑调整，对业务具有一定的侵入性。
• 实施复杂度
  添加主键和唯一索引在运维中算比较普遍的操作，主从环境中，可优先在从库先为表添加主键或者唯一索引，主库可在空闲时禁用会话级binlog再添加，实施难度一般，周期相对短。
• 主从可用性
  仅添加主键，对主从数据同步无调整，添加之后，即可恢复同步，不影响主从可用性。
• 后续影响
  彻底解决麻烦，后续出现大事务，大大降低延迟，这可能是一个最优的方案。

方案二、从库事务跳过

• 业务亲和性
  需要与业务人员确认事务逻辑，评估涉及的SQL范围，但对具体业务逻辑无影响。
• 实施复杂度
  事务跳过在主从环境中，也属于一个比较常见运维，数据库管理人员可操作，从库无论是GITD模式或者非GTID模式，都有相应跳过对应事务的方法，可事先抓取执行SQL，跳过事务后， 手动在从库执行，一旦涉及多条SQL，修复过程相当煎熬，对实施人员专注度要求较高，实施难度稍高，周期相对较短。
• 主从可用性
  除受影响的表外，其他表复制不受影响，在操作得当情况下，主从可用性有一定保障。
• 后续影响
  指标不治本，下次遇到问题还需要手动解决。

方案三、忽略表

• 业务亲和性
  无需和业务进行过多确认，在没有配置读写分离的主从环境，对具体业务逻辑无影响。
• 实施复杂度
  从库复制进程可采用replicate_wild_ignore_table选项暂时忽略此表，业务空闲时，再找办法修复此表，比如在此表数据静止状态下，通过导出导入方式修复，实施难度一般，周期短。
• 主从可用性
  受影响的表在一定时间内数据不一致，主从可用性缺失。
• 后续影响
  需要单独找时间在修复此表，依然指标不治本，而且下次遇到大事务，还需要手动解决。

方案四、全库恢复

• 业务亲和性
  对业务逻辑几乎无影响。
• 实施复杂度
  主从重建，如果库比较大，可能需要协调周边资源，实施难度一般，周期视库大小而定。
• 主从可用性
  重建之后，主从可用性即可恢复。
• 后续影响
  依然指标不治本，而且下次遇到大事务，还需要手动解决。

总结

    通过对上面四种方案的分析，对比如下。

    合适的就是好的，在选择时可依据现场情况，建议优先选择添加主键，当然其他方案也是可以考虑的，之所以说添加主键，不仅是因为它解决了从库延迟，也解决了从库无主键或唯一索引，出现HASH SCAN的BUG，可参考Mysql 因 CRC32 HASH算法BUG造成从库同步异常了解情况。