MGR性能比传统主从低20%–40%，因需多数节点Paxos共识、读写阻塞、网络RTT敏感及write-set校验开销；仅读多写少、单主关检查、合理压缩与配置下才接近主从性能。
MGR性能比传统主从低，写入吞吐量通常下降20%–40%，延迟更高，但这是为强一致性付出的必要代价。
为什么MGR写入更慢
MGR必须等多数节点确认事务顺序（Paxos共识），而传统主从只要写完本地binlog就返回成功。这个“等待多数派”的过程直接拖慢了单个事务的提交时间。
-
group_replication_consistency设为BEFORE_ON_PRIMARY_FAILOVER或更高时，读请求也会被阻塞等待组内同步完成，进一步拉高响应延迟 - 网络RTT每增加1ms，MGR平均事务延迟约上升0.8–1.2ms；传统主从几乎不受影响
- 事务冲突检测（write-set校验）在
group_replication_enforce_update_everywhere_checks=ON时额外消耗CPU，尤其在多主模式下明显
什么时候MGR性能反而接近主从
在只读密集、写入极少的场景下，MGR和传统主从的TPS差距会大幅收窄，因为MGR的开销主要集中在写路径。
- 单主模式下关闭多节点写入检查：
group_replication_enforce_update_everywhere_checks=OFF，可减少约15%的写延迟 - 使用
group_replication_compression_threshold=1048576（1MB）以上才压缩，避免小事务压缩反增CPU开销 - 确保所有节点
binlog_format=ROW且binlog_row_image=FULL，否则认证失败重试会放大延迟
容易被忽略的性能陷阱
很多人调优只盯着MySQL参数，却忘了底层通信层才是瓶颈所在。
- 默认
group_replication_local_address绑定在0.0.0.0:33061，若未显式指定内网IP，可能走错网卡或触发NAT，导致GCS心跳超时、频繁重传 -
group_replication_message_cache_size默认仅1GB，三节点集群在批量导入时极易撑满缓存，引发ER_GROUP_REPLICATION_MESSAGE_CACHE_FULL错误并暂停复制 - MySQL 8.0.28+才支持
group_replication_flow_control_mode=DISABLED，旧版本无法真正关流控，高并发写入时会主动限速
真正决定MGR能不能用的，不是“它比主从慢多少”，而是“你的业务能否容忍写延迟升高、同时又不能接受数据不一致”。金融类系统宁可慢200ms，也不能丢一条订单；报表库则完全没必要上MGR。
