Worker报1032错误本质是无主键表在并行复制下因row_id定位不一致导致，需添加主键或改用LOGICAL_CLOCK模式根治，而非仅跳过事务。
Worker线程报错基本意味着并行复制已启用但执行失败，不能只跳过事务了事——得先确认是哪类错误、触发条件是否满足、底层表结构是否合规。
Worker报1032错误：找不到记录，本质是无主键+并行复制冲突
典型报错：Error_code: 1032; Can't find record in 'tb_inventory_log'; handler error HA_ERR_KEY_NOT_FOUND。这不是数据丢了，而是从库用隐式row_id定位行时跟主库对不上。
- 仅当表没有主键或唯一键，且
binlog_format = ROW时才会触发 -
slave_parallel_workers > 0且slave_parallel_type = WRITESET会放大该问题：事务乱序执行，row_id生成逻辑在主从间不一致 -
sql_slave_skip_counter = 1能临时恢复，但下次同样操作还会报 - 根治办法只有两个：
ALTER TABLE tb_inventory_log ADD PRIMARY KEY (id)，或改用LOGICAL_CLOCK模式（兼容性更好，但并发度略低）
Worker卡在Waiting for preceding transaction to commit：Redo日志瓶颈
现象是多个Worker线程长时间停留在Waiting for preceding transaction to commit，同时ib_log_checkpt线程CPU跑满。这说明InnoDB检查点推进受阻，不是SQL逻辑问题，而是存储层压力溢出。
-
innodb_log_file_size太小（如默认1GB）+ 高写入负载 → Redo日志使用率超85% → 检查点无法刷新脏页 - 机械盘或IOPS不足的云盘会加剧该问题，即使
iostat显示IO util不高，也可能因随机写延迟高导致checkpoint线程卡死 - 临时缓解：调大
innodb_log_file_size（需停库）、降低slave_parallel_workers值（比如从16降到4），避免并发刷脏页争抢 - 长期方案：换SSD、开启
innodb_adaptive_flushing = ON、监控Innodb_redo_log_archived指标
Worker执行Update_rows_v1失败：字符序不兼容中断
报错含Unknown collation: 'utf8mb4_0900_ai_ci'，说明主库导出的建表语句带MySQL 8.0专属排序规则，但从库是5.7或未显式配置兼容collation。
- 不是字符集问题，是
COLLATE值本身不被识别——utf8mb4_0900_ai_ci在5.7完全不存在 -
--compatible=mysql57参数不处理collation，必须手动替换SQL dump里的所有COLLATE utf8mb4_0900_ai_ci为COLLATE utf8mb4_general_ci - 漏掉一处就会卡在
CREATE TABLE阶段，SHOW REPLICA STATUS里Last_SQL_Error明确提示“Unknown collation” - 从库
my.cnf必须加：collation-server = utf8mb4_general_ci和init_connect = 'SET NAMES utf8mb4 COLLATE utf8mb4_general_ci'，否则连接层仍可能用错collation
Worker连不上主库：caching_sha2_password认证失败
Last_IO_Error: Authentication plugin 'caching_sha2_password' reported error: Authentication requires secure connection——这是IO线程启动时就失败，根本到不了SQL回放阶段。
- 主库用户插件确实是
caching_sha2_password，但从库没配RSA公钥或未启用require_secure_transport宽松策略 - 最稳妥的解法不是关SSL，而是把复制用户切回
mysql_native_password：ALTER USER 'repl'@'%' IDENTIFIED WITH mysql_native_password BY 'xxx'; - 如果必须保留
caching_sha2_password，主库要配sha256_password_rsa_public_key_path，且从库连接串加?allowPublicKeyRetrieval=true&useSSL=false（仅测试环境） - 注意：部分旧版MySQL Connector/J不支持新插件，需升级驱动到8.0.x
Worker报错从来不是孤立事件，它背后往往连着表结构缺陷、存储配置失衡、协议版本错配或字符规则断层。修一个sql_slave_skip_counter就像给爆胎的车打气——轮子还在漏，只是暂时能跑。真正要盯住的是SHOW PROCESSLIST里Worker的真实状态、performance_schema.replication_applier_status_by_worker里的错误堆栈，以及SHOW ENGINE INNODB STATUS里检查点和锁等待详情。
