因为基于 GTID 的复制依赖于事务，所以在使用它时不支持 MySQL 中其他可用的一些功能。本节提供有关使用 GTID 进行复制的限制和限制的信息。

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

此限制是由于在同一事务中对使用非事务性存储引擎的表的更新与对使用事务性存储引擎的表的更新混合在一起可能导致将多个 GTID 分配给同一事务。

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

在刚刚提到的任何一种情况下，事务与 GTID 之间的一一对应关系被打破，导致基于 GTID 的复制无法正常运行。

创建表 ... 选择语句。  CREATE TABLE ... SELECT使用基于 GTID 的复制时不允许使用语句。当 binlog_format设置为STATEMENT时，一条CREATE TABLE ... SELECT 语句在二进制日志中记录为一个事务，一个GTID，但如果使用ROW格式，则语句记录为两个事务，两个GTID。如果源使用 STATEMENT 格式而副本使用 ROW 格式，则副本将无法正确处理事务，因此 CREATE TABLE ... SELECTGTID 不允许该语句以防止这种情况发生。

临时表。  使用 GTID（即，当 系统变量设置为）时，在事务、过程、函数和触发器中不支持CREATE TEMPORARY TABLE和 语句。可以在启用 GTID 的情况下使用这些语句，但只能在任何事务之外，并且只能与 . DROP TEMPORARY TABLEenforce_gtid_consistencyONautocommit=1

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

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

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

跳过交易。  sql_slave_skip_counter使用 GTID 时不支持。如果您需要跳过事务，请改用源 gtid_executed变量的值。有关说明，请参阅 第 16.1.7.3 节，“跳过事务”。

忽略服务器。  使用 GTID 时不推荐使用该语句的 IGNORE_SERVER_IDS 选项CHANGE MASTER TO，因为已经应用的事务会被自动忽略。在开始基于 GTID 的复制之前，检查并清除之前在相关服务器上设置的所有忽略的服务器 ID 列表。该 SHOW SLAVE STATUS语句可以针对单个通道发出，如果有的话，会显示被忽略的服务器 ID 列表。如果没有列表，则该 Replicate_Ignore_Server_Ids字段为空白。

GTID 模式和 mysqldump。  可以将使用 mysqldump生成的转储导入到启用了 GTID 模式的 MySQL 服务器中，前提是目标服务器的二进制日志中没有 GTID。

GTID 模式和 mysql_upgrade。  当服务器运行时启用了全局事务标识符 (GTID) ( gtid_mode=ON)，请不要通过mysql_upgrade （--write-binlog 选项）启用二进制日志记录。