由於基於 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 清單）來清除它。