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

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

此限制是由于以下事实造成的：在同一事务中更新使用非事务性存储引擎的表以及更新使用事务性存储引擎的表，可能会导致多个 GTID 被分配给同一事务。

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

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

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

临时表。  如果 binlog_format 设置为 STATEMENT，当服务器上使用 GTID 时（即当 enforce_gtid_consistency 系统变量设置为 ON 时），CREATE TEMPORARY TABLE 和 DROP TEMPORARY TABLE 语句不能在事务、过程、函数和触发器中使用。当使用 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 的复制之前，请检查并清除之前在所涉及的服务器上设置的所有被忽略的服务器 ID 列表。可以使用 SHOW REPLICA STATUS 语句（可以针对各个通道执行）来显示被忽略的服务器 ID 列表（如果有）。如果没有列表，则 Replicate_Ignore_Server_Ids 字段为空。如果被忽略的服务器 ID 列表不为空，则可以使用 CHANGE REPLICATION SOURCE TO ... IGNORE_SERVER_IDS=()（换句话说，使用空服务器 ID 列表来忽略）来清除它。