为什么不能只依赖另一张“详细”表？

另一张常被关注的表是 performance_schema.replication_group_member_stats。它看起来更“详细”，提供了 COUNT_TRANSACTIONS_IN_QUEUE、COUNT_TRANSACTIONS_CHECKED 等指标。但必须清醒地认识到：这张表的数据完全基于本节点的视角进行统计，并且严重依赖组通信层（XCom）的本地缓存。

这意味着，一旦节点网络断开或者XCom内部出现异常，这张表的数据就可能停滞不前，返回陈旧信息，甚至全部变成 NULL。

那么它有什么用呢？它更适合用于本节点的实时负载诊断。比如，当你发现 COUNT_TRANSACTIONS_IN_QUEUE 持续大于100，这通常暗示应用写入速度过快，或者从节点的事务回放速度跟不上。但切记，它无法告诉你集群里其他兄弟节点是否已经掉线。

• 字段 LAST_CONFLICT_FREE_TRANSACTION 在节点异常后常常为空，这并不代表没有事务，只是状态更新机制停滞了。
• 这张表里没有 MEMBER_ID 字段，如果想和 replication_group_members 表关联查询，操作起来很麻烦，容易导致数据遗漏。
• 在高并发写入的场景下，频繁查询此表会加剧 performance_schema 的内存开销。因此，监控采样的间隔建议不小于5秒。

状态变量 group_replication_local_member_state 只能当辅助参考

通过 SHOW VARIABLES LIKE 'group_replication_local_member_state' 查到的这个状态变量，反映的只是本节点插件“自我感觉”的状态，并非集群共识的结果。它的更新速度比 replication_group_members 表更快，但也因此更容易产生误报。

这里容易踩坑：节点刚重启时，插件可能抢先一步报告自己已经是 ONLINE 了，但实际上它还没有完成组内的握手流程。此时，replication_group_members 表里它的状态可能还是 RECOVERING。反过来，一次短暂的网络抖动可能导致该变量瞬间变成 ERROR，但几秒钟后它又自动恢复了，而表里的状态变化通常会有一些延迟。

• 它只包含本节点信息，是纯粹的“本地视角”，无法替代需要聚合所有节点状态的监控需求。
• 当它的值变为 UNREACHABLE 时，正确的做法是立即检查 group_replication_ip_whitelist 配置和防火墙策略，而不是仅仅盯着这个变量就匆忙重启服务。
• 如果在监控脚本里只依赖这个变量来触发告警，大概率会收获一堆令人头疼的“闪断误报”。

编写监控SQL时，绕不开的兼容性与性能细节

MySQL 8.0.27 是一个重要的分水岭。在这个版本之前，replication_group_members 表缺少 MEMBER_VERSION 和 MEMBER_COMMUNICATION_STACK 字段；而到了8.0.33版本，又新增了 MEMBER_ROLE 字段。如果你的生产集群横跨多个小版本，那么监控SQL必须做好字段存在性判断，否则在低版本节点上执行时会直接报出 Unknown column 错误。

性能方面也需要留意：这张表本身是内存映射的，单次查询很快。但如果你的监控系统以每秒数次的频率轮询，并且还关联（JOIN）查询其他 performance_schema 表，则可能引发内部锁竞争，反而导致主库的 COMMIT 延迟升高。

• 安全的写法是明确列出字段，避免使用 SELECT *。例如：SELECT MEMBER_ID, MEMBER_STATE, MEMBER_ROLE FROM performance_schema.replication_group_members。
• 不要在监控脚本里简单使用 WHERE MEMBER_STATE != 'ONLINE' 作为唯一的告警条件——因为一个新节点加入集群时，其状态会正常经历 OFFLINE → RECOVERING → ONLINE 的流程，中间的 RECOVERING 阶段是合理的，不应触发告警。
• 对于生产环境，建议在监控查询中加上执行超时提示，例如 /*+ MAX_EXECUTION_TIME(1000) */，防止某一条缓慢的查询拖垮整个监控采集线程。

话说回来，监控MGR真正的难点，在于如何将“集群状态”与“业务影响”对齐。一个节点明明标着 ONLINE，但它的 applier_queue_size 可能已经堆积了上千个事务。这时，它对读请求或许是健康的，但对于那些要求强一致性的写请求，却可能面临超时风险。这种状态与性能的割裂，光盯着状态表是永远发现不了的。