GTID 怎样查看组复制事务标识

查看 MySQL 组复制的事务标识，先读取 @@GLOBAL.group_replication_group_name 和 @@GLOBAL.gtid_executed：前者帮助辨认组产生事务的 UUID，后者列出当前实例已经执行的 GTID 集合。再查询 performance_schema.replication_group_member_stats，即可结合成员身份观察最近通过冲突检查的事务以及全成员已提交集合。三个视角不能互相代替。

官方文档：https://dev.mysql.com/doc/refman/8.4/en/group-replication-gtids.html。本文采用 MySQL 8.4 文档中的字段，给出只读查询及会话变量示例，未在本机运行数据库；示意 UUID 不代表真实集群。

先用最小查询区分实例、组和事务集合

-- 只读查询：记录当前连接实例与复制组的标识。
SELECT @@GLOBAL.server_uuid AS instance_uuid,
       @@GLOBAL.group_replication_group_name AS group_uuid;

-- 读取本实例已执行的 GTID 集合，不表示全组实时交集。
SELECT @@GLOBAL.gtid_executed AS local_executed;

server_uuid 标识当前 MySQL 实例，group_replication_group_name 标识复制组。组直接接收的客户端事务通常使用组名作为 GTID 的 UUID 部分，因此看见 GTID 前缀不等于某个成员的 UUID，并不代表查错实例。

一个不带标签的 GTID 可写作 UUID:事务序号，同一来源的连续事务在集合中可压缩为区间。判断时要同时读 UUID 和区间，不能只看末尾最大的数字。不同 UUID 下的相同序号也不是同一个事务。

本机已执行集合可能同时包含组事务、加入组前的历史事务及外部异步复制保留的来源标识。它不是单纯的“本组业务订单列表”，也不包含可直接阅读的 SQL 正文。

确认 MySQL 版本与组复制运行范围

-- 查询版本及 GTID 模式；不修改任何复制配置。
SELECT VERSION() AS mysql_version,
       @@GLOBAL.gtid_mode AS gtid_mode,
       @@GLOBAL.enforce_gtid_consistency AS consistency_mode;

-- 当前视角下的组成员、角色与状态。
SELECT MEMBER_ID, MEMBER_HOST, MEMBER_PORT, MEMBER_STATE, MEMBER_ROLE
FROM performance_schema.replication_group_members;

先把版本与成员状态保留下来，再解释 GTID。查询返回多个成员行，是当前节点看到的组成员信息；若连接经代理转发，应确认实际连到的实例。本文不通过修改 GTID 模式来修复查询环境，也不要求重启组复制。

若变量不存在，应先核对是否为 Oracle MySQL、插件是否可用以及版本差异。若统计表没有数据，要结合组复制是否运行、成员状态和查询账号权限判断，不能直接认定“没有任何事务”。遇到拒绝访问应申请所需的查询权限，不应为一次查看使用不限范围的高权限账号。

关联成员表查看组内事务统计

-- 按通道和成员关联，避免把不同成员的统计拼在一起。
SELECT m.MEMBER_ID, m.MEMBER_HOST, m.MEMBER_STATE,
       s.VIEW_ID,
       s.LAST_CONFLICT_FREE_TRANSACTION,
       s.TRANSACTIONS_COMMITTED_ALL_MEMBERS,
       s.COUNT_TRANSACTIONS_REMOTE_IN_APPLIER_QUEUE
FROM performance_schema.replication_group_members AS m
LEFT JOIN performance_schema.replication_group_member_stats AS s
  ON s.MEMBER_ID = m.MEMBER_ID
 AND s.CHANNEL_NAME = m.CHANNEL_NAME
ORDER BY m.MEMBER_ID;

关联条件包含成员 ID 和通道名，查询结果才能保留“哪一个成员、哪个复制通道”的上下文。这里使用左关联，是为了让缺少统计行的成员仍可见；空值表示这次关联没有取得统计，不能当作计数为零。

一笔事务通过冲突检查与它在各成员完成应用不是同一个观察点。业务要确认某次写入可读，应遵守应用的一致性方案；不能把统计表的某一行替代一致性等待或事务读取约定。

用集合运算判断指定事务是否已执行

-- 示意值：执行前替换为实际要查的完整 GTID，不可照抄 UUID。
SET @wanted = 'aaaaaaaa-bbbb-cccc-dddd-eeeeeeeeeeee:128';

-- 固定同一次读取的本机集合，供两个集合表达式共同使用。
SET @local_set = @@GLOBAL.gtid_executed;
SELECT GTID_SUBSET(@wanted, @local_set) AS present_on_this_member,
       GTID_SUBTRACT(@wanted, @local_set) AS missing_on_this_member;

上例只设置当前连接的用户变量，不改变 GTID 配置。present_on_this_member 为 1 表示目标集合包含在捕获的本机集合中；missing_on_this_member 为空字符串表示该快照下没有缺少的目标事务。若目标是多个 GTID，也可沿用相同集合运算。

这是基于一次集合快照的判断。持续写入时，分别连接多台机器所得结果并非同一时刻的全组快照；发现差异需要结合采样时间、成员状态及待应用队列理解。不要用字符串相等或文本包含搜索比较 GTID 集合，它们不能正确表达区间包含关系。

兼容处理、查询开销与常见疑问

如果旧版本缺少某个统计列，先按该版本官方字段列表删减投影列；本机 gtid_executed 仍只提供本机视角，不能在降级后改称全组结果。自动化采集应使用明确列名并保留实例身份和时间，而不是依赖 SELECT * 的列顺序。

GTID 集合可能很长，不宜高频将所有成员的完整集合写入日志。常规监控可先记录成员状态及计数；要排查指定事务时，再做目标集合比较。统计更新存在时间间隔，即使刷新页面也不意味着远端信息同步更新。

为什么同一组的 GTID 里有多个 UUID？

外部复制和历史事务可能保留原来源标识，视图变更也可能使用单独配置的 UUID。先查来源配置与历史，不能仅凭多个 UUID 判定复制异常。

为什么最大事务序号有跳跃？

组复制存在 GTID 分块分配机制，序号不是业务行数或严格连续的业务计数。应比较完整集合的区间，不能把数值跳跃直接当作数据丢失。

全组提交集合能证明业务数据完全一致吗？

它描述复制事务的提交统计，不能单独证明应用查询、非事务对象及所有历史人工操作都一致。查看事务标识时应保持这个结论范围。

参考入口：组复制 GTID https://dev.mysql.com/doc/refman/8.4/en/group-replication-gtids.html；统计字段 https://dev.mysql.com/doc/refman/8.4/en/performance-schema-replication-group-member-stats-table.html；GTID 集合函数 https://dev.mysql.com/doc/refman/8.4/en/gtid-functions.html。