本文內容來自《高效能MySQL》，自己整理了一下。

  儲存引擎的事務特效能夠保證在儲存引擎級別實現ACID。而分散式事務則讓儲存引擎級別的ACID可以擴充套件到資料庫層面，甚至可以擴充套件到多個數據庫之間--這需要兩階段提交實現。MySQL5.0和更新版本的資料庫已經開始支援XA事務了。

  XA事務中需要有一個事務協調器來保證所有的事務參與者都完成了準備工作（第一階段）。如果協調器收到所有的參與者都準備好的訊息，就會告訴所有的事務可以提交了，這是第二階段。MySQL在這個XA事務過程中扮演一個參與者的角色，而不是協調者。

  實際上，在MySQL中有兩種XA事務。一方面，MySQL可以參與到外部的分散式事務中，另一方面，還可以通過XA事務來協調儲存引擎和二進位制日誌。

內部XA事務

  MySQL本身的外掛式架構導致在其內部需要使用XA事務。MySQL中各個儲存引擎是完全獨立的，彼此不知道對方的存在，所以一個跨儲存引擎的事務就需要一個外部的協調者。如果不使用XA協議，例如，跨儲存引擎的事務提交就只是順序地要求每個儲存引擎各自提交。如果在某個儲存提交過程中發生系統崩潰，就會破壞事務的特性（要麼就全部提交，要麼就不做任何操作）。如果將MySQL記錄的二進位制日誌操作看作一個獨立的“儲存引擎”，就不難理解為什麼即使是一個儲存引擎參與的事務仍然需要XA事務了。在儲存引擎提交的同時，需要將“提交”的資訊寫入二進位制日誌，這就是一個分散式事務，只不過二進位制日誌的參與者是MySQL本身。

  XA事務為MySQL帶來巨大的效能下降。從MySQL5.0開始，它破壞了MySQL內部的“批量提交”（一種通過單磁碟I/O操作完成多個事務提交的技術），使得MySQL不得不進行多次額外的fsync()呼叫。具體的，一個事務如果開啟了二進位制日誌，則不僅需要對二進位制日誌進行持久化操作，InnoDB事務日誌還需要兩次日誌持久化操作。換句話說，如果希望有二進位制日誌安全的事務實現，則至少需要做三次fsync()操作。唯一避免這個問題的辦法就是關閉二進位制日誌，並將innodb_support_xa設定為0。

  但是這樣的設定是非常不安全的，而且這會導致MySQL複製也沒法正常工作。複製需要二進位制日誌和XA事務的支援，另外--如果希望資料儘可能安全--最好還要講sync--binlog設定為1，這時儲存引擎和二進位制日誌才是真正同步的。（否則，XA事務支援就沒有意義了，因為事務提交了二進位制日誌卻可能沒有“提交”到磁碟。）這也是為什麼我們強烈建議使用帶電池保護的RAID卡寫快取：這個快取可以大大加快fsync()操作的效率。

外部XA事務

  MySQL能夠作為參與者完成一個外部的分散式事務。但它對XA協議支援並不完整，例如，XA協議要求在一個事務中的多個連線可以做關聯，但目前的MySQL版本還不能支援。

  因為通訊延遲和參與者本身可能失敗，所以外部XA事務比內部消耗會更大。如果在廣域網中使用XA事務，通常會因為不可預測的網路效能導致事務失敗。如果有太多不可控因素，例如，不穩定的網路通訊或者使用者長時間地等待而不提交，則最好避免使用XA事務。任何可能讓事務提交發生延遲的操作代價都很大，因為它影響的不僅僅是自己本身，它還會讓所有參與者都在等待。

  別的方式實現分散式事務：可以在本地寫入資料，並將其放入佇列，然後在一個更小、更快的事務中自動分發。還可以使用MySQL本身的複製機制來發送資料。

  XA事務是一種在多個伺服器之間同步資料的方法。如果由於某些原因不能使用MySQL本身的複製，或者效能並不是瓶頸的時候，可以嘗試使用。