Die XA-Transaktionsunterstützung beschränkt sich auf die Speicher-Engine InnoDB.

Die XA-Implementierung von MySQL ist für „externes XA“ ausgelegt, bei dem ein MySQL Server als Ressourcenmanager (RMs) und Clientprogramme als Transaktionsmanager (TMs) fungieren. „Internes XA“ ist nicht implementiert. Dies würde einzelnen Speicher-Engines in einem MySQL Server erlauben, als RMs zu agieren, und dem Server selbst, als TM zu fungieren. Internes XA ist für den Umgang mit XA-Transaktionen erforderlich, an denen mehr als eine Speicher-Engine beteiligt ist. Die Implementierung von internem XA ist unvollständig, da sie erfordert, dass eine Speicher-Engine zweiphasiges Commit auf der Tabellenhandler-Ebene unterstützt, was zurzeit nur InnoDB kann.

Für XA START werden keine JOIN- und RESUME-Klauseln unterstützt.

Für XA END wird die SUSPEND [FOR MIGRATE]-Klausel nicht unterstützt.

Die Anforderung, dass der bqual-Teil des xid-Werts für jede XA-Transaktion innerhalb einer globalen Transaktion anders sein muss, ist eine Beschränkung der derzeitigen XA-Implementierung von MySQL. Sie ist nicht Teil der XA-Spezifikation.

Wenn eine XA-Transaktion den PREPARED-Zustand erreicht hat und der MySQL Server abstürzt, kann die Transaktion nach dem erneuten Hochfahren des Servers weiterlaufen. Das soll auch so sein. Wenn allerdings die Clientverbindung abbricht und der Server weiterläuft, rollt der Server alle anhängigen XA-Transaktionen zurück, selbst solche, die den PREPARED-Zustand erreicht haben. Es sollte möglich sein, eine PREPARED-XA-Transaktion zu committen oder zurückzurollen, doch dies lässt sich nur durch Änderungen am Mechanismus des Binärlogs erreichen.