典型情况是服务器为已提交事务生成新的GTID。然而，GTIDs也可以分配给其他变化，某些情况下一个事务可以分配多个GTIDs。

每个数据库变化（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 COMMIT或XA ROLLBACK阶段分配单独的GTID。XA事务是持久准备的，以便在失败时可以提交或回滚（在复制拓扑结构中可能包括服务器故障）。因此，这两个事务部分需要单独的GTID，即使非XA事务回滚不需要GTID。

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

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

请注意，在将gtid_next设置为特定的GTID（在UUID:NUMBER或UUID:TAG:NUMBER格式）后，事务已经提交或回滚，您需要在执行任何其他语句之前执行明确的SET @@SESSION.gtid_next语句。您可以使用该语句将GTID值设置回AUTOMATIC，以便不再明确地分配GTID。

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

客户端可以模拟复制事务，通过设置@@SESSION.gtid_next到特定的GTID，然后执行事务。这项技术由mysqlbinlog用于生成二进制日志的备份，该客户端可以重新播放该备份以保留GTID。模拟的复制事务提交通过客户端是与通过复制应用程序线程提交的复制事务相同的，且无法在事后区分。

在gtid_purged系统变量（@@GLOBAL.gtid_purged）中包含了服务器上所有已提交的事务的GTID，但这些事务不在服务器上的任何二进制日志文件中。gtid_purged是gtid_executed的子集。以下是gtid_purged中的GTID类别：

您可以将gtid_purged的值更改，以在服务器上记录某个GTID集中的事务已经被应用，但是这些事务在服务器上的任何二进制日志中都不存在。将GTIDs添加到gtid_purged中，也将其添加到gtid_executed中。该操作的示例用例是，您正在恢复一个或多个数据库的备份，但是您没有在服务器上拥有相关的二进制日志文件中的事务。您也可以选择将指定的GTID集替换gtid_purged中的整个GTID集，或者将指定的GTID集添加到gtid_purged中的GTIDs中。有关如何执行此操作的详细信息，请参阅gtid_purged的描述。

在gtid_executed和gtid_purged系统变量的GTID集在服务器启动时初始化。每个二进制日志文件都以事件Previous_gtids_log_event开始，该事件包含所有前一个二进制日志文件中的GTID集（由前一个文件的Previous_gtids_log_event和前一个文件中的每个Gtid_log_event组成）。最老和最新的二进制日志文件中的Previous_gtids_log_event内容用于计算gtid_executed和gtid_purged的值在服务器启动时：

如果您需要在服务器上重置 GTID 执行历史记录，请使用 RESET BINARY LOGS AND GTIDS 语句。您可能需要在新 GTID 服务器上执行测试查询以验证复制设置，也可能需要在加入复制组的新服务器上，但该服务器包含一些不想被 Group Replication 接受的本地事务。

在执行 RESET BINARY LOGS AND GTIDS 之前，请确保您已经备份了服务器的二进制日志文件和二进制日志索引文件，如果有，请保存 gtid_executed 系统变量的全局值（例如，通过执行 SELECT @@GLOBAL.gtid_executed 语句并保存结果）。如果您要从该 GTID 集合中删除不想要的事务，请使用 mysqlbinlog 来检查事务内容，以确保它们没有价值、没有保存或复制的数据、没有在服务器上进行数据更改。

当您执行 RESET BINARY LOGS AND GTIDS 时，以下操作将被执行：

请注意，即使服务器是副本且二进制日志记录被禁用，也可以使用RESET BINARY LOGS AND GTIDS重置 GTID 执行历史。 RESET REPLICA 对 GTID 执行历史无效。