MySQL并行复制需同时满足主库binlog_row_image=FULL且从库slave_parallel_type设为LOGICAL_CLOCK（5.7+）或COMMIT_ORDER（8.0+），仅设slave_parallel_workers无效。
为什么 slave_parallel_workers 设了却没效果
MySQL 并行复制默认不生效，光设 slave_parallel_workers 不够，必须同时满足两个前提：主库开启 binlog_row_image=FULL（推荐），且从库的 slave_parallel_type 必须设为 LOGICAL_CLOCK（MySQL 5.7+）或 COMMIT_ORDER（8.0+）。否则即使开了 16 个 worker，所有事件仍被塞进单个协调线程排队执行。
检查方式：
SHOW VARIABLES LIKE 'slave_parallel%';<br>SHOW VARIABLES LIKE 'binlog_row_image';
-
slave_parallel_type错设为DATABASE：只按库并行，跨库更新少时几乎无加速 - 主库
binlog_format是STATEMENT：逻辑时钟无法生成，LOGICAL_CLOCK失效 - 从库重启后未重载配置：需
SET PERSIST或写入my.cnf并重启 mysqld
长事务怎么精准定位和拆解
主从延迟常由单个大事务拖累，比如一个 UPDATE 扫描千万行、或 ALTER TABLE 未加 ALGORITHM=INSTANT。不能只看 Seconds_Behind_Master，它可能突然跳变，要抓实时阻塞点。
在从库执行：
SELECT * FROM performance_schema.replication_applier_status_by_coordinator\G<br>SELECT * FROM performance_schema.replication_applier_status_by_worker\G
- 关注
WORKER_ID = 0的协调线程是否长期STATE = 'Waiting for an event from coordinator'：说明有大事务未分发 - 查
replication_applier_status_by_worker中TASKS列非空且STATE停在Executing event超过 30 秒：对应线程正在处理长事务 - 结合
SHOW PROCESSLIST看该 worker 对应的THREAD_ID正在跑什么 SQL（需开启performance_schema和events_statements_current）
并行复制下主键冲突或唯一键重复怎么办
启用 LOGICAL_CLOCK 后，不同 worker 可能并发执行同一张表的 DML，若业务未显式加锁或依赖自增主键顺序，容易触发 Duplicate entry 或 Deadlock found 错误，导致复制中断。
关键不是关并行，而是收敛写入模式：
STOP SLAVE;<br>SET GLOBAL slave_exec_mode='IDEMPOTENT';<br>START SLAVE;
-
slave_exec_mode=IDEMPOTENT允许主键/唯一键冲突时跳过报错（仅限 ROW 格式），但不解决数据逻辑一致性问题 - 更稳妥的是在应用层把批量写拆成小批次（如每次 1000 行），用
INSERT ... ON DUPLICATE KEY UPDATE替代REPLACE - 避免在从库上执行
CREATE TEMPORARY TABLE或写mysql系统库——这些语句不会被并行调度，反而卡住协调线程
为什么 Seconds_Behind_Master 显示 0 却仍有延迟
这个值只反映 relay log 最后一条事件的时间戳与当前系统时间差，不反映实际数据可见性。常见假象包括：主库大量短事务堆积未刷盘、从库 IO 线程卡在磁盘写 relay log、或者开启了 relay_log_recovery=ON 但 recovery 过程未完成。
- 用
SHOW SLAVE STATUS\G检查Seconds_Behind_Master为 0 时，Read_Master_Log_Pos和Exec_Master_Log_Pos是否持续增长但差值稳定：说明 IO 线程在拉日志，SQL 线程已追平，但数据还没刷到磁盘 - 查
SHOW ENGINE INNODB STATUS的LOG部分，看Log sequence number与Log flushed up to差距是否过大（> 100MB） -
relay_log_space_limit设太小会导致频繁轮转 relay log，引发 IO 等待，建议设为 4G~8G
真正卡住同步的，往往是那些没出现在监控里、但持续占用 row lock 的隐式事务，还有 innodb_flush_log_at_trx_commit=1 和 sync_binlog=1 在高并发下的写放大效应——这些细节比调几个并行参数更影响实际延迟。
