由于基于 GTID 的复制依赖于事务，因此一些在 MySQL 中可用的功能在使用它时不受支持。本节提供有关使用 GTID 的复制限制的信息。

涉及非事务性存储引擎的更新。 在使用 GTID 时，对使用非事务性存储引擎（如 MyISAM）的表的更新不能与对使用事务性存储引擎（如 InnoDB）的表的更新在同一个语句或事务中进行。

此限制是由于这样一个事实，即在同一事务内对使用非事务性存储引擎的表进行更新与对使用事务性存储引擎的表进行更新混合在一起，会导致为同一事务分配多个 GTID。

当源和副本对同一表的各自版本使用不同的存储引擎时，也可能出现此类问题，其中一个存储引擎是事务性的，而另一个不是。还要注意，为在非事务性表上操作而定义的触发器可能是导致这些问题的原因。

在上述任何情况下，事务和 GTID 之间的一对一对应关系都会被破坏，结果是基于 GTID 的复制无法正常工作。

CREATE TABLE ... SELECT 语句。 对于支持原子 DDL 的存储引擎，CREATE TABLE ... SELECT 在二进制日志中记录为一个事务。有关更多信息，请参见 第 15.1.1 节“原子数据定义语句支持”。

临时表。 如果 binlog_format 设置为 STATEMENT，CREATE TEMPORARY TABLE 和 DROP TEMPORARY TABLE 语句在服务器上使用 GTID 时（即，当 enforce_gtid_consistency 系统变量设置为 ON 时），不能在事务、过程、函数和触发器内使用。当 GTID 正在使用时，它们可以在这些上下文之外使用，前提是 autocommit=1 设置。当 binlog_format 设置为 ROW 或 MIXED 时，当 GTID 正在使用时，CREATE TEMPORARY TABLE 和 DROP TEMPORARY TABLE 语句可以在事务、过程、函数或触发器内使用。这些语句不会写入二进制日志，因此不会复制到副本。使用基于行的复制意味着副本保持同步，而无需复制临时表。如果从事务中删除这些语句导致空事务，则该事务不会写入二进制日志。

防止执行不支持的语句。 为了防止执行会导致基于 GTID 的复制失败的语句，所有服务器在启用 GTID 时，必须使用 --enforce-gtid-consistency 选项启动。这将导致本节前面讨论的任何类型的语句都以错误失败。

请注意，--enforce-gtid-consistency 仅在对语句进行二进制日志记录时才生效。如果服务器上的二进制日志记录被禁用，或者语句由于被过滤器删除而没有写入二进制日志，则不会对未记录的语句进行 GTID 一致性检查或强制执行。

有关启用 GTID 时其他必需的启动选项的信息，请参阅 第 19.1.3.4 节，“使用 GTID 设置复制”。

跳过事务。 sql_replica_skip_counter 在使用基于 GTID 的复制时不可用。如果需要跳过事务，请使用源的 gtid_executed 变量的值。如果已使用 CHANGE REPLICATION SOURCE TO 语句的 ASSIGN_GTIDS_TO_ANONYMOUS_TRANSACTIONS 选项在复制通道上启用了 GTID 赋值，则 sql_replica_skip_counter 可用。有关更多信息，请参阅 第 19.1.7.3 节，“跳过事务”。

忽略服务器。 IGNORE_SERVER_IDS 不能与 CHANGE REPLICATION SOURCE TO 一起使用，因为在使用 GTID 时，已应用的事务会自动被忽略。在开始基于 GTID 的复制之前，请检查并清除已在涉及的服务器上设置的所有忽略的服务器 ID 列表。SHOW REPLICA STATUS 语句（可以针对各个通道发出）会显示忽略的服务器 ID 列表（如果有）。如果没有列表，则 Replicate_Ignore_Server_Ids 字段为空。如果忽略的服务器 ID 列表不为空，则可以使用 CHANGE REPLICATION SOURCE TO ... IGNORE_SERVER_IDS=()（换句话说，使用要忽略的服务器 ID 的空列表）清除它。