MySQL 8.0 不存在“匿名事务”功能，所谓匿名事务是对ROW格式下事务标记缺失或mysqlbinlog工具注释的误读；真实可用的主从迁移特性是CLONE_PLUGIN和GROUP_REPLICATION。
MySQL 8.0 并没有“匿名事务”这个功能——这是个常见误解。官方文档和源码中均无 anonymous transaction 概念，所谓“匿名事务”通常是对 BINLOG_FORMAT=ROW 下无显式事务标记、或误读 mysqlbinlog --skip-generate-events 行为的误称。
为什么你查不到 anonymous_transaction 相关配置或系统变量？
MySQL 8.0 的事务标识始终依赖 GTID（如果启用）或 file:position（传统复制）。Binlog 中每条事件都归属于某个事务，事务开头必有 Query_log_event（如 BEGIN）或 Xid_log_event（提交），不存在“匿名”一说。
- 搜索
SHOW VARIABLES LIKE '%anonymous%'或SELECT * FROM performance_schema.* WHERE ...都不会返回任何匹配项 -
mysqlbinlog解析输出里可能出现# anonymous注释，但这只是工具对缺失SET @@SESSION.GTID_NEXT的临时标注，不是 MySQL 服务端行为 - 某些运维脚本用“匿名”指代未显式
START TRANSACTION的单语句自动提交事务，但这类事务在 binlog 中依然有完整事务边界
真正能简化主从迁移的 MySQL 8.0 特性是 GROUP_REPLICATION 和 CLONE_PLUGIN
如果你的目标是减少停机、避免手动导出导入、跳过传统 mysqldump + CHANGE MASTER TO 流程，应该聚焦这两个真实可用的功能：
-
CLONE_PLUGIN：允许从节点直接克隆主节点数据目录（含 binlog position），一条命令完成全量同步：CLONE LOCAL DATA DIRECTORY = '/path/to/clone'; -
GROUP_REPLICATION：基于 Paxos 的多主/单主集群，新节点加入时自动拉取并应用缺失事务，无需人工计算Exec_Master_Log_Pos - 二者都要求主从 MySQL 版本一致（至少同为 8.0.17+），且
binlog_format=ROW、gtid_mode=ON、enforce_gtid_consistency=ON
误信“匿名事务”可能导致的典型故障
当团队基于错误认知设计迁移方案时，常出现以下问题：
- 试图用
mysqlbinlog --skip-generate-events过滤“匿名事务”，结果跳过关键 DDL，导致从库表结构不一致 - 在
CHANGE MASTER TO时随意指定MASTER_LOG_FILE和MASTER_LOG_POS，假设“没 BEGIN 就是匿名”，实际位置已越界，复制报错Could not find first log file name in binary log index file - 关闭
gtid_mode后依赖 position 迁移，却忽略relay_log_recovery=ON，重启从库后 relay log 断链，无法追平
迁移主从架构的关键从来不是虚构的“匿名事务”，而是精确控制 GTID 集合范围、确保 binlog 完整保留、以及用 CLONE 或 GROUP_REPLICATION 替代手工同步。那些被当成“捷径”的模糊概念，往往在凌晨三点的复制延迟告警里露出真面目。
