查MGR成员状态应优先查询performance_schema.replication_group_members表，其中MEMBER_STATE为ONLINE才真正可用，RECOVERING表示同步中，OFFLINE说明插件未启动，ERROR或UNREACHABLE需立即排查；其他方式如SHOW STATUS或information_schema旧表不可靠。
查 MGR 成员状态，优先看 performance_schema.replication_group_members
MySQL 8.0+ 的 MGR 集群成员在线/离线/恢复中等状态，最直接、最权威的来源就是这张表。它不依赖外部工具，也不需要解析日志，只要节点本身还能响应 SQL 查询，就能反映当前视图。
常见错误现象：用 SHOW STATUS LIKE 'group_replication%' 或查 information_schema 下的旧表（如 GROUP_REPLICATION_MEMBERS），这些要么字段缺失、要么已废弃、要么返回空——尤其在节点已失联但尚未被踢出组时，performance_schema 表仍保留最后上报状态，而其他方式可能直接不显示该成员。
-
MEMBER_STATE是关键字段：值为ONLINE才算真正可用；RECOVERING表示还在同步事务；OFFLINE说明插件没启动；ERROR或UNREACHABLE要立刻排查网络或崩溃日志 -
MEMBER_ROLE在单主模式下只有PRIMARY和SECONDARY；多主模式下全是PRIMARY，不能靠这个判断写入能力 - 注意
MEMBER_VERSION：版本不一致可能导致无法加入组，比如 8.0.33 节点尝试加入 8.0.31 组，即使能连上也会卡在RECOVERING
为什么不能只依赖 SELECT * FROM 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关联，强行 JOIN 容易漏数据 - 在高并发写入下，频繁查这张表会加剧
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，中间阶段属于正常流程 - 生产环境建议加
/*+ MAX_EXECUTION_TIME(1000) */提示，防止单条查询拖垮监控采集线程
真正难的是把“状态”和“业务影响”对齐：一个节点标着 ONLINE，但它的 applier_queue_size 已经堆积几千事务，这时候它对读请求是健康的，对一致性要求高的写请求却可能超时。这种割裂，光看状态表永远发现不了。
