典型的场景是服务器为提交的事务生成一个新的 GTID。但是，GTID 也可以分配给事务之外的其他更改，在某些情况下，单个事务可以分配多个 GTID。

写入二进制日志的每个数据库更改（DDL 或 DML）都会分配一个 GTID。这包括自动提交的更改，以及使用 BEGIN和COMMIT或 START TRANSACTION语句提交的更改。GTID 还分配给数据库和非表数据库对象（例如过程、函数、触发器、事件、视图、用户、角色或授权）的创建、更改或删除。

非事务性更新和事务性更新都分配有 GTID。此外，对于非事务性更新，如果在尝试写入二进制日志缓存时发生磁盘写入失败并因此在二进制日志中创建间隙，则生成的事件日志事件将分配一个 GTID。

当二进制日志中生成的语句自动删除表时，会为该语句分配一个 GTID。当副本开始应用来自刚刚启动的源的事件时，以及当基于语句的复制正在使用 ( binlog_format=STATEMENT) 并且具有打开的临时表的用户会话断开连接时，临时表将自动删除。使用MEMORY存储引擎的表在服务器启动后第一次访问时会自动删除，因为行可能在关闭期间丢失。

当事务未写入原始服务器上的二进制日志时，服务器不会为其分配 GTID。这包括回滚的事务和在原始服务器上禁用二进制日志记录时执行的事务，全局（--skip-log-bin 在服务器配置中指定）或会话（SET @@SESSION.sql_log_bin = 0）。这还包括使用基于行的复制时的无操作事务 ( binlog_format=ROW)。

XA 事务为事务的XA PREPARE阶段和事务的XA COMMITorXA ROLLBACK阶段分配了单独的 GTID。XA 事务是持久准备的，以便用户可以提交它们或在发生故障时回滚它们（在复制拓扑中可能包括到另一台服务器的故障转移）。因此，事务的两个部分被单独复制，所以它们必须有自己的 GTID，即使回滚的非 XA 事务不会有 GTID。

在以下特殊情况下，单个语句可以生成多个事务，因此被分配多个 GTID：

默认情况下，对于在用户会话中提交的新事务，服务器会自动生成并分配一个新的 GTID。当事务应用于副本时，来自原始服务器的 GTID 将被保留。gtid_next 您可以通过设置系统变量 的会话值来更改此行为：

请注意，在设置 gtid_next为特定 GTID 并且事务已提交或回滚后，SET @@SESSION.gtid_next必须在任何其他语句之前发出显式语句。AUTOMATIC如果您不想明确分配任何更多 GTID，则可以使用它来将 GTID 值设置回。

当复制应用程序线程应用复制的事务时，它们使用这种技术， @@SESSION.gtid_next明确设置为在源服务器上分配的复制事务的 GTID。这意味着来自原始服务器的 GTID 将被保留，而不是由副本生成和分配新的 GTID。gtid_executed这也意味着即使在副本上禁用二进制日志记录或副本更新日志记录，或者事务是空操作或在副本上被过滤掉时， GTID 也会添加到 副本上。

客户端可以通过@@SESSION.gtid_next在执行事务之前设置为特定的 GTID 来模拟复制的事务。mysqlbinlog使用此技术 生成二进制日志的转储，客户端可以重播该转储以保留 GTID。通过client提交的模拟复制事务与通过replication applier线程提交的复制事务完全等同，事后无法区分。

gtid_purged系统变量 ( ) 中的 GTID 集 @@GLOBAL.gtid_purged包含已在服务器上提交的所有事务的 GTID，但不存在于服务器上的任何二进制日志文件中。 gtid_purged是 的一个子集 gtid_executed。以下类别的 GTID 位于 gtid_purged：

您可以更改 的值， gtid_purged以便在服务器上记录已应用某个 GTID 集中的事务，尽管它们不存在于服务器上的任何二进制日志中。当您将 GTID 添加到 时 gtid_purged，它们也会添加到gtid_executed. 此操作的一个示例用例是当您在服务器上恢复一个或多个数据库的备份时，但您没有包含服务器上事务的相关二进制日志。在 MySQL 8.0 之前，您只能更改 gtid_purgedwhen 的值gtid_executed（因此 gtid_purged) 是空的。从 MySQL 8.0 开始，这个限制不再适用，您还可以选择是否将整个 GTID 集替换 gtid_purged为指定的 GTID 集，或者将指定的 GTID 集添加到已经存在的 GTID 中 gtid_purged。有关如何执行此操作的详细信息，请参阅 的说明 gtid_purged。

gtid_executed和 系统变量中 的 GTID 集在 gtid_purged服务器启动时初始化。每个二进制日志文件都以 event 开头 Previous_gtids_log_event，它包含所有先前二进制日志文件中的 GTID 集（由前面文件中的 GTID 和前面文件本身Previous_gtids_log_event中每个文件的 GTID 组成）。最旧和最新的二进制日志文件中的 Gtid_log_event内容 用于在服务器启动 时计算和 集合：Previous_gtids_log_eventgtid_executedgtid_purged

如果这些计算涉及来自 MySQL 5.7.7 或更早版本的二进制日志，则可能会为gtid_executed和 计算出不正确的 GTID 集gtid_purged，并且即使稍后重新启动服务器，它们仍然不正确。有关详细信息，请参阅 binlog_gtid_simple_recovery 系统变量的说明，该变量控制二进制日志如何迭代以计算 GTID 集。如果那里描述的情况之一适用于服务器，请设置 binlog_gtid_simple_recovery=FALSE 在启动服务器之前在服务器的配置文件中。该设置使服务器迭代所有二进制日志文件（不仅仅是最新的和最旧的）以查找 GTID 事件开始出现的位置。如果服务器有大量没有 GTID 事件的二进制日志文件，此过程可能需要很长时间。

如果您需要重置服务器上的 GTID 执行历史记录，请使用该RESET MASTER语句。例如，您可能需要在执行测试查询以验证新启用 GTID 的服务器上的复制设置之后执行此操作，或者当您想要将新服务器加入复制组但它包含一些不被接受的不需要的本地事务时通过组复制。

在发出之前RESET MASTER，确保您有服务器的二进制日志文件和二进制日志索引文件的备份，如果有的话，并获取并保存在 gtid_executed系统变量的全局值中保存的 GTID 集（例如，通过发出SELECT @@GLOBAL.gtid_executed语句并保存结果）。如果要从该 GTID 集中删除不需要的事务，请使用mysqlbinlog检查事务的内容以确保它们没有价值，不包含必须保存或复制的数据，并且不会导致服务器上的数据更改。

当您发出RESET MASTER时，将执行以下重置操作：

请注意，这RESET MASTER是重置 GTID 执行历史记录的方法，即使服务器是禁用二进制日志记录的副本。 RESET REPLICA对 GTID 执行历史没有影响。