MGR写冲突需查performance_schema事务表，重点关注events_transactions_history_long中STATE='COMMITTING'且WORK_COMPLETED=0的记录，结合replication_group_member_stats的认证队列指标及INNODB STATUS定位热点行。
查 performance_schema 里的事务冲突记录
MySQL Group Replication（MGR）本身不直接暴露“写冲突”错误，冲突在提交阶段被检测并拒绝，真正落地的指标藏在 performance_schema 的事务表里。重点看 events_transactions_history_long 和 replication_applier_status_by_coordinator。
常见错误现象是应用报 ER_TRANSACTION_ROLLBACK_DURING_COMMIT 或 Deadlock found when trying to get lock，但这类错误未必出现在客户端日志——它可能已被 MGR 内部静默回滚。
- 启用必要消费者：
UPDATE performance_schema.setup_consumers SET ENABLED = 'YES' WHERE NAME IN ('events_transactions_history_long', 'events_transactions_current'); - 查询最近被中止的事务：
SELECT EVENT_ID, TRX_ID, STATE, WORK_COMPLETED, WORK_ESTIMATED, TIMER_WAIT FROM performance_schema.events_transactions_history_long WHERE STATE = 'COMMITTING' AND WORK_COMPLETED = 0 ORDER BY TIMER_START DESC LIMIT 10; - 注意
WORK_COMPLETED = 0是关键信号，表示事务在提交阶段失败，大概率是冲突或认证失败
盯紧 replication_group_members 和 replication_group_member_stats
MGR 冲突不是孤立事件，常伴随成员状态抖动、延迟升高或认证队列积压。这两张表能反映底层压力源，比单纯查错误日志更早发现问题。
使用场景：当发现某节点吞吐下降但无明显错误时，优先查这里。
-
replication_group_members中MEMBER_STATE长时间处于RECOVERING或OFFLINE，说明该节点反复因冲突/超时被踢出，需检查网络或事务粒度 -
replication_group_member_stats中COUNT_TRANSACTIONS_VALIDATING持续 > 1000，说明认证队列严重堆积，冲突概率陡增；COUNT_TRANSACTIONS_ROWS_VALIDATING过高则提示热点行竞争 - 注意：这些字段只在 MySQL 8.0.22+ 完整支持，低版本需依赖
performance_schema.table_lock_waits_summary_by_table间接观察锁等待
用 SHOW ENGINE INNODB STATUS 快速定位热点行冲突
当确认存在高频写冲突，但无法定位具体表或行时，SHOW ENGINE INNODB STATUS 的 TRANSACTIONS 部分比慢日志更直接——它会列出当前阻塞链和最后执行的 SQL。
性能影响小，可每 5 分钟采样一次，适合线上快速排查。
- 重点关注输出中
---TRANSACTION ... ACTIVE ... sec后面的mysql tables in use和LOCK WAIT行 - 若多个事务都卡在
waiting for table metadata lock或同一PRIMARY KEY上，基本锁定热点主键或索引设计问题 - 别依赖
information_schema.INNODB_TRX，它只显示活跃事务，而冲突往往发生在已提交但未通过认证的事务上，INNODB_STATUS才包含完整上下文
避免误读 group_replication_flow_control_mode 的“假稳定”
设成 QUOTA 模式后，监控看到 flow_control_period 波动变小，容易误判“系统健康”。其实这是流控在强行压制写入，掩盖了底层冲突——它没解决冲突，只是把冲突延后或转移给了客户端超时。
兼容性影响：MySQL 8.0.26+ 才支持 DISABLED 模式下仍采集认证队列指标；老版本关流控后，replication_group_member_stats 的统计会失真。
- 监控脚本里不要只看
flow_control_mode = QUOTA就认为安全，必须同步检查COUNT_TRANSACTIONS_VALIDATING和applier_status的LAST_ERROR_NUMBER - 如果
LAST_ERROR_NUMBER = 3092（即ER_GROUP_REPLICATION_MEMBER_NOT_RESPONDING），大概率是某节点因冲突频繁重连，触发心跳失败判定 - 最易忽略的一点：MGR 冲突日志默认不写入 error log，除非显式开启
log_error_verbosity = 3，否则你根本看不到Transaction certification failed这类原始提示
