MySQL 8.0中“并行的GTID”不存在，GTID仅提供事务唯一标识与自动位点管理；真正提升从库回放速度需配置GTID（gtid_mode=ON、enforce_gtid_consistency=ON）与并行复制组合（slave_parallel_type=LOGICAL_CLOCK、slave_parallel_workers=4–16、slave_preserve_commit_order=ON），并确保主库启用WRITESET依赖追踪及ROW格式。
MySQL 8.0 中没有“并行的 GTID”这个概念——GTID 本身是事务级唯一标识，不提供并行能力；所谓“并行复制”是另一个独立机制（slave_parallel_workers），它可与 GTID 共存，但两者无直接耦合。真正要配的是「GTID + 并行复制」组合，目标是提升从库回放速度，同时保持复制位置自动管理。
确认 MySQL 8.0 版本并检查 GTID 基础支持
GTID 在 MySQL 5.6.5+ 引入，但生产环境强烈建议用 8.0.22+，因早期版本对 STOP REPLICA、SOURCE_AUTO_POSITION 等语法支持不完整。
执行以下命令快速验证：
SELECT VERSION(); SHOW VARIABLES LIKE 'gtid_mode'; SHOW VARIABLES LIKE 'enforce_gtid_consistency';
必须看到 gtid_mode 为 ON、enforce_gtid_consistency 为 ON，否则后续所有配置都无效。若为 OFF 或 OFF_PERMISSIVE，说明 GTID 尚未启用，不能跳过配置步骤直接开并行。
主从两端统一配置 GTID 关键参数
主库和从库的 my.cnf 的 [mysqld] 段必须同时包含以下几项，缺一不可：
-
server_id：每台机器唯一，不能重复（如主库设1，从库设2） -
log_bin = mysql-bin：必须开启 binlog，GTID 依赖它 -
binlog_format = ROW：GTID 要求严格行格式，MIXED或STATEMENT会触发enforce_gtid_consistency拒绝执行 -
gtid_mode = ON：核心开关 -
enforce_gtid_consistency = ON：禁止CREATE TABLE ... SELECT、事务内建临时表等不安全语句 -
log_slave_updates = ON：从库也要写 binlog，否则级联复制或故障切换时无法继续
改完重启 MySQL。注意：MySQL 8.0 不支持在线动态开启 gtid_mode，必须重启生效。
启用并行复制（基于 WRITESET）
MySQL 8.0 默认并行策略是 DATABASE，效率低；推荐用 WRITESET，它能跨库并行，前提是主库已开启 binlog_transaction_compression = ON（非必需但推荐）且事务写集（writeset）信息被记录。
在从库上执行：
STOP REPLICA; SET PERSIST parallel_applier_type = 'LOGICAL_CLOCK'; SET PERSIST parallel_applier_workers = 4; SET PERSIST relay_log_recovery = ON; START REPLICA;
关键点：
-
parallel_applier_type = 'LOGICAL_CLOCK'是 8.0 中WRITESET并行的前提（实际由binlog_transaction_dependency_tracking控制，但用户不直设） -
parallel_applier_workers建议设为 CPU 核数的 1–2 倍，过高反而因锁争用降低吞吐 -
relay_log_recovery = ON必须开启，否则重启后并行线程可能状态错乱 - 不要设
slave_parallel_type = LOGICAL_CLOCK—— 这是 MySQL 5.7 的旧参数，8.0 已废弃，用错会导致START REPLICA失败
启动 GTID 复制并验证是否真走并行
从库连接主库时，必须用 SOURCE_AUTO_POSITION = 1（不是已弃用的 MASTER_AUTO_POSITION = 1）：
CHANGE REPLICATION SOURCE TO SOURCE_HOST='master_ip', SOURCE_USER='repl', SOURCE_PASSWORD='xxx', SOURCE_AUTO_POSITION = 1;
启动后检查是否真正并行：
-
SHOW REPLICA STATUS\G中Slave_SQL_Running_State显示类似worker 2 is waiting for an event from coordinator表示多线程已工作 -
SELECT * FROM performance_schema.replication_applier_status_by_worker;查看各 worker 的LAST_SEEN_TRANSACTION是否不同，且WORKER_ID > 0 - 若
Seconds_Behind_Master持续为 0 但Retrieved_Gtid_Set≠Executed_Gtid_Set，说明并行线程卡在某个事务依赖上（常见于大事务或 DDL）
最容易被忽略的是：即使开了并行，单个大事务（如一个 UPDATE 影响百万行）仍会阻塞所有 worker，因为 writeset 无法拆分。这时候得靠业务拆分事务，而不是调高 parallel_applier_workers。
