gtid模式本身不直接导致性能波动，但高并发下gtid_owned集合清理阶段的线程级互斥锁（lock_sidno）引发tps锯齿状抖动；binlog_format=row与enforce_gtid_consistency=on进一步放大日志开销与解析检查负担。
gtid_mode=ON 本身不直接导致性能“波动”，但会引入 GTID 分配与维护的锁竞争路径，尤其在高并发事务场景下，这种竞争会表现为 TPS 不稳定、响应时间毛刺——也就是你观察到的“小幅波动”。
真正起作用的是 GTID 内部状态管理的并发瓶颈，不是配置开关本身。
gtid_owned 集合清理阶段的线程级互斥锁
事务提交后，每个线程需从 gtid_owned 集合中移除自己持有的 GTID。这个操作必须加全局互斥锁（lock_sidno），且由各线程**独立触发**，不走 group commit 协同路径。
常见现象：
- pt-pmp 堆栈高频出现
ha_commit_trans → Gtid_state::update_owned_gtids_impl → lock_sidno - 并发写入突增时，
SHOW PROCESSLIST中大量线程卡在commit状态 - TPS 曲线呈锯齿状，而非持续下降
这不是 bug，是设计使然：MySQL 5.7 的 GTID 状态管理未对高并发清理做无锁或分段优化。
binlog_format=ROW + gtid_mode=ON 组合放大日志开销
开启 GTID 后，所有事务 Binlog 必须包含 Gtid_log_event，且 binlog_format=ROW（GTID 强制要求）会记录完整行镜像。这带来两个隐性成本：
- 每条 DML 日志体积增大（尤其大字段、JSON、TEXT 列），刷盘压力上升
-
sync_binlog=1时，事务提交延迟直接受磁盘 I/O 影响，抖动更易暴露 - 从库 SQL 线程必须严格按 GTID 顺序重放，无法跳过冲突事务，重放队列堆积会反压主库
注意：binlog_row_image=MINIMAL 可减小日志体积，但不能绕过 GTID 事件本身的固定开销。
enforce_gtid_consistency=ON 触发额外语义检查
该参数启用后，MySQL 在语句解析阶段就做事务安全校验，例如：
- 拒绝
CREATE TABLE ... SELECT、CREATE TEMPORARY TABLE - 拦截混合事务表（InnoDB + MyISAM）更新
- 对函数、触发器、存储过程做额外上下文扫描
这些检查本身很快，但在连接密集、短事务高频提交场景下，累积效应会让 parser 阶段耗时变得可感知，尤其当 optimizer_switch 中某些规则（如 condition_fanout_filter）也同时开启时，抖动会被放大。
容易被忽略的点：slave_parallel_workers 和 GTID 并行度不匹配
5.7 的多线程复制依赖 GTID 分组，但 slave_parallel_workers 设置过高（比如 >8）反而引发 coordinator 线程调度争抢，导致从库回放延迟抖动，进而通过半同步等机制间接拖慢主库 commit 返回。
实操建议：
- 先确认是否真为“主库波动”：用
pt-stalk抓取主库SHOW ENGINE INNODB STATUS和performance_schema.events_statements_summary_by_digest，排除慢查询或锁等待干扰 - 若确认是 GTID 锁瓶颈，优先调低
innodb_thread_concurrency（如设为 0 或 16），缓解线程调度与 GTID 清理的叠加竞争 - 不要盲目调大
gtid_executed缓存（它不影响分配路径），而应关注binlog_cache_size是否足够，避免频繁 flush 加剧锁持有时间
GTID 的价值在于复制一致性与故障切换可靠性，它的“小幅波动”本质是为强一致性付出的可控代价——关键不在消除，而在识别它是否真的成了瓶颈。
