由於基於 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 設定複製」。

跳過交易。使用基於 GTID 的複製時，sql_replica_skip_counter 不可用。如果需要跳過交易，請改用來源的 gtid_executed 變數的值。如果使用 CHANGE REPLICATION SOURCE TO 語句的 ASSIGN_GTIDS_TO_ANONYMOUS_TRANSACTIONS 選項在複製通道上啟用了 GTID 指派，則可以使用 sql_replica_skip_counter。如需更多資訊，請參閱第 19.1.7.3 節「跳過交易」。

忽略伺服器。當使用 GTID 時，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 列表）。