MySQL 5.7并行复制需同时配置slave_parallel_type='LOGICAL_CLOCK'和slave_parallel_workers>0才生效，仅设workers无效；必须主库binlog_format=ROW、从库禁用DATABASE模式，并避开跨库DML、无主键表等雷区。
主从延迟不是配置没调对，而是从库 SQL 线程扛不住并发写入——默认单线程回放，主库一并发，它就卡死。解决方向很明确：让从库能并行执行，同时避开并行复制的典型雷区。
为什么 slave_parallel_workers 设了还是没效果？
设了参数但 Seconds_Behind_Master 依然涨，大概率是并行复制没真正启用。MySQL 5.7+ 默认用 LOGICAL_CLOCK 算法，但它依赖事务间逻辑时序，而以下情况会让算法退化为单线程：
- 主库用了
MIXED或STATEMENT格式：必须切到ROW——执行SET GLOBAL binlog_format = 'ROW'并确认已写入配置文件 - 事务跨库（比如
UPDATE db1.t1 JOIN db2.t2）：MySQL 无法判断依赖关系，强制串行回放；业务上尽量避免跨库 DML - 从库开启了
innodb_flush_log_at_trx_commit = 1且磁盘慢：这会拖慢每个事务提交，间接压制并行吞吐，可权衡设为 2（需接受极小概率 crash loss）
SHOW SLAVE STATUS 显示 0 却查不到新数据？
Seconds_Behind_Master = 0 只代表 relay log 已读完、SQL 线程空闲，并不保证刚提交的事务已落地。常见于大事务场景：
- 主库一个事务更新 50 万行，
SHOW SLAVE STATUS仍显示 0，但从库SELECT COUNT就是少几万条——因为事务还没提交，SQL 线程在等它结束 - 此时看
Slave_SQL_Running_State字段，常是Reading event from the relay log或Executing event，而非Slave has read all relay log - 真实延迟得靠
pt-heartbeat：主库每秒写心跳表，从库查时间差，这才是业务可感知的延迟
并行复制开启后报错 Error_code: 1032 怎么办？
这是并行复制最典型的“踩坑即停”错误，本质是事务乱序导致从库找不到要更新的那行。根本原因几乎都是表缺主键或唯一索引：
- ROW 格式下，MySQL 靠主键定位行；没主键时用隐式
row_id，但主从各自维护，值必然不一致 - 执行
SELECT table_schema, table_name FROM information_schema.tables WHERE table_schema NOT IN ('mysql','information_schema','performance_schema','sys') AND table_name NOT IN (SELECT table_name FROM information_schema.key_column_usage WHERE constraint_name = 'PRIMARY' GROUP BY table_name)扫出所有无主键表 - 加主键不能只
ALTER TABLE ... ADD PRIMARY KEY——如果已有重复数据会失败；先CREATE UNIQUE INDEX去重，再转主键
硬件和网络这些“隐形瓶颈”怎么快速验证？
别急着改参数，先排除物理层问题。很多团队把从库配成低配机器，又跑备份+报表，等于给 SQL 线程套了三道枷锁：
- 查
iostat -x 1：从库%util持续 >90% 或await>50ms，说明磁盘 IO 是瓶颈，SSD 换 NVMe 或分离 relay log 到高速盘 - 对比主从
SHOW PROCESSLIST：从库若长期有Waiting for table metadata lock，说明 DDL（如ALTER TABLE）在从库卡住，得停掉从库上的长查询再操作 - 用
tcpdump抓包看主从间 binlog 传输速率：如果平均 10MB/s，就是网络或网卡限速了
并行复制不是开个参数就完事，它把问题从“追不上”变成了“别追错”。真正卡点永远在表结构、binlog 格式、IO 能力这三块——漏掉任何一个，调参都是白忙。
