mysql 8.0主从复制提速需主从协同配置：slave_parallel_type必须设为logical_clock（非writeset），主库启用binlog_transaction_dependency_tracking=writeset，且relay_log_info_repository与master_info_repository均须为table。
MySQL 8.0 的主从复制不是“只要改个参数就能提速”，而是依赖一套主从协同的配置组合，漏配一项，WRITESET 并行就完全失效。
slave_parallel_type 必须设为 LOGICAL_CLOCK，不是 WRITESET
这是最容易配错的地方：很多人看到“WRITESET”就下意识去改 slave_parallel_type，结果设成 WRITESET，MySQL 直接报错或静默降级为单线程。
-
slave_parallel_type在 8.0 中合法值只有DATABASE和LOGICAL_CLOCK；WRITESET是binlog_transaction_dependency_tracking的取值，不是 parallel_type - 设成
LOGICAL_CLOCK才能启用基于 write_set 的调度逻辑；设成DATABASE会退回到按库名分发的老模式，完全无视行级冲突检测 - 从库启动时若发现
slave_parallel_type = WRITESET，5.7 兼容模式下可能忽略，但 8.0 会拒绝启动或报Unknown system variable 'slave_parallel_type'
主库必须开启 binlog_transaction_dependency_tracking = WRITESET
这个参数决定主库怎么生成事务依赖信息。不设它，从库收不到 write_set，再怎么配从库都白搭。
- 默认值是
COMMIT_ORDER（即 5.7 的组提交逻辑），必须显式改为WRITESET - 配套参数
transaction_write_set_extraction建议保持默认XXHASH64，乱改成XXHASH64以外的值（如MURMUR32）会导致主从哈希不一致，出现“明明无冲突却卡住”的诡异现象 - 该参数只对 GTID 模式下的事务生效；如果主库还用
binlog_format = STATEMENT，write_set 根本不会生成
从库 relay_log_info_repository 必须为 TABLE
WRITESET 并行依赖精确的事务边界记录和 worker 状态持久化，而 FILE 模式无法保证 crash safe 的并行回放状态恢复。
- 若仍用
relay_log_info_repository = FILE，从库重启后可能丢失 worker 分配记录，导致部分事务重复执行或跳过 - 必须搭配
master_info_repository = TABLE，否则 coordinator 无法可靠读取主库位点，worker 调度会失序 - 这两个参数在 8.0 中默认已是
TABLE，但如果从 5.7 升级上来，配置文件里没显式写，实际运行时可能沿用旧值
sql_mode 差异会间接破坏复制链路
看似无关的 sql_mode 配置，可能让主库成功执行的语句在从库报错中断复制。
- 主库是 5.7、从库是 8.0 时，若主库备份中含
NO_AUTO_CREATE_USER，从库恢复时直接启动失败，复制根本建不起来 - 主从
sql_mode不一致（比如主库宽松、从库严格），可能导致同一条 INSERT 因字段截断、零日期等被从库拒绝，Slave_SQL_Running_State卡在Executing event - 升级过程中务必统一清理掉已移除项：
NO_AUTO_CREATE_USER、DB2、ORACLE等，且建议主从都显式设置为STRICT_TRANS_TABLES,NO_ENGINE_SUBSTITUTION保底
真正难的不是记住哪几个参数，而是理解 WRITESET 是主从两端共同参与的一次协作——主库负责“算出改了哪些行”，从库负责“比对这些行有没有重叠”。任意一端掉链子，就退回 5.7 式的脆弱并行。
