GTID开启后SQL线程成单点瓶颈，因slave_preserve_commit_order=1强制串行提交，即使启用并行复制（LOGICAL_CLOCK）也需等待依赖事务；同时GTID校验、ROW格式解析及read_only限制进一步加剧延迟。
GTID开启后SQL线程变单点瓶颈
MySQL在GTID模式下默认仍使用单SQL线程回放，但GTID要求事务提交顺序必须严格保持全局一致性（slave_preserve_commit_order=1 默认启用）。这意味着即使启用了并行复制，只要事务之间存在依赖（比如同一张表的前后更新），SQL线程就必须串行等待——不是不能并行，而是不敢乱序提交。结果就是大量事务在SQL线程入口排队，Seconds_Behind_Master 持续上涨，看起来像“性能下降”，实则是强一致性带来的调度收敛。
- 检查是否真卡在SQL线程：执行
SHOW PROCESSLIST，看是否有大量线程状态为Waiting for dependent transaction to commit - 确认并行配置是否生效：查
slave_parallel_type是否为LOGICAL_CLOCK，slave_parallel_workers是否 > 0 - 注意：若
slave_parallel_type=DATABASE，而业务集中在单库（如只有db_app），那并行线程实际还是空转
GTID校验和事务元数据开销增加
每个事务在GTID模式下不仅要写入原始binlog event，还要额外记录 Previous_gtid_log_event 和完整的 Gtid_log_event，同时从库SQL线程每次执行前都要做GTID去重检查（避免重复执行已应用过的事务）。这部分元数据解析+查表（mysql.gtid_executed）在高TPS场景下会明显抬高CPU消耗，尤其当 gtid_mode=ON 且 enforce_gtid_consistency=ON 同时启用时，主库还会对不合规语句直接报错拦截，间接导致应用重试增多、流量放大。
面向 CRM 系统的 MySQL 8 数据库模式设计。当用户需要为客户关系管理（CRM）系统设计、评审、优化或生成数据库模式时，应使用此项技能。
- 典型现象：
SHOW SLAVE STATUS\G中Exec_Master_Log_Pos增长缓慢，但Relay_Log_Space持续飙升 → 说明IO线程拉得快，SQL线程解析/校验慢 - 可临时关闭GTID校验压测对比：设
slave_sql_verify_checksum=OFF（仅测试用，生产慎用） - 确保
mysql.gtid_executed表是 InnoDB 引擎，否则在大事务后可能因 MyISAM 表锁引发阻塞
binlog_format=ROW + GTID 放大日志体积与解析压力
GTID本身不强制ROW格式，但生产环境几乎都搭配使用。而 binlog_format=ROW 下，一个批量UPDATE可能生成数万行变更记录，每行都带完整主键+旧值+新值+GTID头。从库SQL线程不仅要反序列化这些数据，还要根据主键定位行、加锁、执行更新——这比STATEMENT模式下“执行一条SQL”成本高得多。尤其当从库buffer pool不足或磁盘I/O弱于主库时，这种压力会被进一步放大。
- 验证是否为ROW格式拖累：对比
SHOW MASTER LOGS中binlog文件增长速度，再看从库Relay_Log_Space增速是否接近（若远高于，说明网络或IO没问题，问题在SQL层） - 避免无谓膨胀：确认
binlog_row_image=FULL是必需的；若业务只改少量列，可考虑MINIMAL（但需确保从库能安全回放） - 别忽略索引：ROW模式下，从库更新效率极度依赖目标表是否有合适索引；缺失主键或二级索引会导致全表扫描式更新
从库read_only=ON 导致内部优化被禁用
很多团队为防误操作给从库设了 read_only=ON，这看似安全，却让MySQL自动禁用部分写优化路径。例如：InnoDB在只读实例中会跳过某些redo log刷盘逻辑，但GTID模式下，从库SQL线程的“写”本质是事务重放，它仍需完整走事务提交流程。此时 read_only 可能干扰内部状态判断，导致锁竞争加剧、purge线程调度异常，甚至触发更多隐式锁等待。
- 这不是bug，但确实存在行为差异：官方文档明确指出
read_only会影响部分内部并发控制逻辑 - 可尝试临时关闭观察：
SET GLOBAL read_only=OFF，再START SLAVE，对比延迟变化（注意：仅限排查，线上务必恢复） - 更稳妥做法：保持
read_only=ON，但确保super_read_only=OFF（否则连DBA都不可执行管理命令）
