START TRANSACTION, COMMIT和ROLLBACK语法
START TRANSACTION | BEGIN [WORK]
COMMIT [WORK] [AND [NO] CHAIN] [[NO] RELEASE]
ROLLBACK [WORK] [AND [NO] CHAIN] [[NO] RELEASE]
SET AUTOCOMMIT = {0 | 1}
START TRANSACTION或BEGIN语句可以开始一项新的事务。COMMIT可以提交当前事务，是变更成为永久变更。ROLLBACK可以 回滚当前事务，取消其变更。SET AUTOCOMMIT语句可以禁用或启用默认的autocommit模式，用于当前连接。

自选的WORK关键词被支持，用于COMMIT和RELEASE，与CHAIN和RELEASE子句。CHAIN和RELEASE可以被用于对事务完成进行附加控制。Completion_type系统变量的值决定了默认完成的性质。请参见5.3.3节，“服务器系统变量”。

AND CHAIN子句会在当前事务结束时，立刻启动一个新事务，并且新事务与刚结束的事务有相同的隔离等级。RELEASE子句在终止了当前事务后，会让服务器断开与当前客户端的连接。包含NO关键词可以抑制CHAIN或RELEASE完成。如果completion_type系统变量被设置为一定的值，使连锁或释放完成可以默认进行，此时NO关键词有用。

默认情况下，MySQL采用autocommit模式运行。这意味着，当您执行一个用于更新（修改）表的语句之后，MySQL立刻把更新存储到磁盘中。

如果您正在使用一个事务安全型的存储引擎（如InnoDB, BDB或NDB簇），则您可以使用以下语句禁用autocommit模式：

SET AUTOCOMMIT=0;
通过把AUTOCOMMIT变量设置为零，禁用autocommit模式之后，您必须使用COMMIT把变更存储到磁盘中，或着如果您想要忽略从事务开始进行以来做出的变更，使用ROLLBACK。

如果您想要对于一个单一系列的语句禁用autocommit模式，则您可以使用START TRANSACTION语句：

START TRANSACTION;
SELECT @A:=SUM(salary) FROM table1 WHERE type=1;
UPDATE table2 SET summary=@A WHERE type=1;
COMMIT;
使用START TRANSACTION，autocommit仍然被禁用，直到您使用COMMIT或ROLLBACK结束事务为止。然后autocommit模式恢复到原来的状态。

BEGIN和BEGIN WORK被作为START TRANSACTION的别名受到支持，用于对事务进行初始化。START TRANSACTION是标准的SQL语法，并且是启动一个ad-hoc事务的推荐方法。BEGIN语句与BEGIN关键词的使用不同。BEGIN关键词可以启动一个BEGIN...END复合语句。后者不会开始一项事务。请参见20.2.7节，“BEGIN ... END复合语句”。

您也可以按照如下方法开始一项事务：

START TRANSACTION WITH CONSISTENT SNAPSHOT;
WITH CONSISTENT SNAPSHOT子句用于启动一个一致的读取，用于具有此类功能的存储引擎。目前，该子句只适用于InnoDB。该子句的效果与发布一个START TRANSACTION，后面跟一个来自任何InnoDB表的SELECT的效果一样。请参见15.2.10.4节，“一致的非锁定读”。

开始一项事务会造成一个隐含的UNLOCK TABLES被执行。

为了获得最好的结果，事务应只使用由单一事务存储引擎管理的表执行。否则，会出现以下问题：

·         如果您使用的表来自多个事务安全型存储引擎（例如InnoDB和BDB），并且事务隔离等级不是SERIALIZABLE，则有可能当一个事务提交时，其它正在进行中的、使用同样的表的事务将只会发生由第一个事务产生的变更。也就是，用混合引擎不能保证事务的原子性，并会造成不一致。（如果混合引擎事务不经常有，则您可以根据需要使用SET TRANSACTION ISOLATION LEVEL把隔离等级设置到SERIALIZABLE。）

·         如果您在事务中使用非事务安全型表，则对这些表的任何变更被立刻存储，不论autocommit模式的状态如何。

如果您在更新了事务中一个事务表之后，发布一个ROLLBACK语句，则会出现一个ER_WARNING_NOT_COMPLETE_ROLLBACK警告。对事务安全型表的变更被 回滚，但是对非事务安全型表没有变更。

每个事务被存储在一个组块中的二进制日志中，在COMMIT之上。被回滚的事务不被计入日志。（例外情况：对非事务表的更改不会被 回滚。如果一个被回滚的事务包括对非事务表的更改，则整个事务使用一个在末端的ROLLBACK语句计入日志，以确保对这些表的更改进行复制。）见5.11.3节，“二进制日志”。

您可以使用SET TRANSACTION ISOLATION LEVEL更改事务的隔离等级。请参见13.4.6节，“SET TRANSACTION语法”。

回滚可以慢速运行。在用户没有明确要求时，也可以进行回滚（例如，当错误发生时）。因此，在明确地和隐含的（ROLLBACK SQL命令）回滚时，SHOW PROCESSLIST会在Stage列中显示Rolling back，用于连接。

不能回滚的语句
有些语句不能被回滚。通常，这些语句包括数据定义语言（DDL）语句，比如创建或取消数据库的语句，和创建、取消或更改表或存储的子程序的语句。

您在设计事务时，不应包含这类语句。如果您在事务的前部中发布了一个不能被回滚的语句，则后部的其它语句会发生错误，在这些情况下，通过发布ROLLBACK语句不能 回滚事务的全部效果。

会造成隐式提交的语句
以下语句（以及同义词）均隐含地结束一个事务，似乎是在执行本语句前，您已经进行了一个COMMIT。

·         ALTER FUNCTION, ALTER PROCEDURE, ALTER TABLE, BEGIN, CREATE DATABASE, CREATE FUNCTION, CREATE INDEX, CREATE PROCEDURE, CREATE TABLE, DROP DATABASE, DROP FUNCTION, DROP INDEX, DROP PROCEDURE, DROP TABLE, LOAD MASTER DATA, LOCK TABLES, RENAME TABLE, SET AUTOCOMMIT=1, START TRANSACTION, TRUNCATE TABLE, UNLOCK TABLES.

·         当当前所有的表均被锁定时，UNLOCK TABLES可以提交事务。

·         CREATE TABLE, CREATE DATABASE DROP DATABASE, TRUNCATE TABLE, ALTER FUNCTION, ALTER PROCEDURE, CREATE FUNCTION, CREATE PROCEDURE, DROP FUNCTION和DROP PROCEDURE等语句会导致一个隐含提交。

·         InnoDB中的CREATE TABLE语句被作为一个单一事务进行处理。这意味着，来自用户的ROLLBACK不会撤销用户在事务处理过程中创建的CREATE TABLE语句。

事务不能被嵌套。这是隐含COMMIT的结果。当您发布一个START TRANSACTION语句或其同义词时，该COMMIT被执行，用于任何当前事务。

SAVEPOINT和ROLLBACK TO SAVEPOINT语法
SAVEPOINT identifier
ROLLBACK [WORK] TO SAVEPOINT identifier
RELEASE SAVEPOINT identifier
InnoDB支持SQL语句SAVEPOINT, ROLLBACK TO SAVEPOINT, RELEASE SAVEPOINT和自选的用于ROLLBACK的WORK关键词。

SAVEPOINT语句用于设置一个事务保存点，带一个标识符名称。如果当前事务有一个同样名称的保存点，则旧的保存点被删除，新的保存点被设置。

ROLLBACK TO SAVEPOINT语句会向以命名的保存点回滚一个事务。如果在保存点被设置后，当前事务对行进行了更改，则这些更改会在 回滚中被撤销。但是，InnoDB不会释放被存储在保存点之后的存储器中的行锁定。（注意，对于新插入的行，锁定信息被存储在行中的事务ID承载；锁定没有被分开存储在存储器中。在这种情况下，行锁定在撤销中被释放。）在被命名的保存点之后设置的保存点被删除。

如果语句返回以下错误，则意味着不存在带有指定名称的保存点：

ERROR 1181: Got error 153 during ROLLBACK
RELEASE SAVEPOINT语句会从当前事务的一组保存点中删除已命名的保存点。不出现提交或 回滚。如果保存点不存在，会出现错误。

如果您执行COMMIT或执行不能命名保存点的ROLLBACK，则当前事务的所有保存点被删除。

LOCK TABLES和UNLOCK TABLES语法
LOCK TABLES
    tbl_name [AS alias] {READ [LOCAL] | [LOW_PRIORITY] WRITE}
    [, tbl_name [AS alias] {READ [LOCAL] | [LOW_PRIORITY] WRITE}] ...
UNLOCK TABLES
LOCK TABLES可以锁定用于当前线程的表。如果表被其它线程锁定，则造成堵塞，直到可以获取所有锁定为止。UNLOCK TABLES可以释放被当前线程保持的任何锁定。当线程发布另一个LOCK TABLES时，或当与服务器的连接被关闭时，所有由当前线程锁定的表被隐含地解锁。

表锁定只用于防止其它客户端进行不正当地读取和写入。保持锁定（即使是读取锁定）的客户端可以进行表层级的操作，比如DROP TABLE。

注意，下面是对事务表使用LOCK TABLES的说明：

·         在尝试锁定表之前，LOCK TABLES不是事务安全型的，会隐含地提交所有活性事务。同时，开始一项事务（例如，使用START TRANSACTION），会隐含地执行UNLOCK TABLES。（见13.4.3节，“会造成隐式提交的语句”。

·         对事务表（如InnoDB）使用LOCK TABLES的正确方法是，设置AUTOCOMMIT=0并且不能调用UNLOCK TABLES，直到您明确地提交事务为止。当您调用LOCK TABLES时，InnoDB会内部地取其自己的表锁定，MySQL取其自己的表锁定。InnoDB在下一个提交时释放其表锁定，但是，对于MySQL，要释放表锁定，您必须调用UNLOCK TABLES。您不应该让AUTOCOMMIT=1，因为那样的话，InnoDB会在调用LOCK TABLES之后立刻释放表锁定，并且很容易形成死锁定。注意，如果AUTOCOMMIT=1，我们根本不能获取InnoDB表锁定，这样就可以帮助旧的应用软件避免不必要的死锁定。

·         ROLLBACK不会释放MySQL的非事务表锁定。

要使用LOCK TABLES，您必须拥有相关表的LOCK TABLES权限和SELECT权限。

使用LOCK TABLES的主要原因是仿效事务，或在更新表时加快速度。这将在后面进行更详细的解释。

如果一个线程获得对一个表地READ锁定，该线程（和所有其它线程）只能从该表中读取。如果一个线程获得对一个表的WRITE锁定，只有保持锁定的线程可以对表进行写入。其它的线程被阻止，直到锁定被释放时为止。

READ LOCAL和READ之间的区别是，READ LOCAL允许在锁定被保持时，执行非冲突性INSERT语句（同时插入）。但是，如果您正打算在MySQL外面操作数据库文件，同时您保持锁定，则不能使用READ LOCAL。对于InnoDB表，READ LOCAL与READ相同。

当您使用LOCK TABLES时，您必须锁定您打算在查询中使用的所有的表。虽然使用LOCK TABLES语句获得的锁定仍然有效，但是您不能访问没有被此语句锁定的任何的表。同时，您不能在一次查询中多次使用一个已锁定的表——使用别名代替，在此情况下，您必须分别获得对每个别名的锁定。

mysql> LOCK TABLE t WRITE, t AS t1 WRITE;
mysql> INSERT INTO t SELECT * FROM t;
ERROR 1100: Table 't' was not locked with LOCK TABLES
mysql> INSERT INTO t SELECT * FROM t AS t1;
如果您的查询使用一个别名引用一个表，那么您必须使用同样的别名锁定该表。如果没有指定别名，则不会锁定该表。

mysql> LOCK TABLE t READ;
mysql> SELECT * FROM t AS myalias;
ERROR 1100: Table 'myalias' was not locked with LOCK TABLES
相反的，如果您使用一个别名锁定一个表，您必须使用该别名在您的查询中引用该表。

mysql> LOCK TABLE t AS myalias READ;
mysql> SELECT * FROM t;
ERROR 1100: Table 't' was not locked with LOCK TABLES
mysql> SELECT * FROM t AS myalias;
WRITE锁定通常比READ锁定拥有更高的优先权，以确保更新被尽快地处理。这意味着，如果一个线程获得了一个READ锁定，则另一个线程会申请一个WRITE锁定，后续的READ锁定申请会等待，直到WRITE线程获得锁定并释放锁定。您可以使用LOW_PRIORITY WRITE锁定来允许其它线程在该线程正在等待WRITE锁定时获得READ锁定。只有当您确定最终将有一个时机，此时没有线程拥有READ锁定时，您才应该使用LOW_PRIORITY WRITE锁定。

LOCK TABLES按照如下方式执行：

1.    按照内部定义的顺序，对所有要被锁定的表进行分类。从用户的角度，此顺序是未经定义的。

2.    如果使用一个读取和一个写入锁定对一个表进行锁定，则把写入锁定放在读取锁定之前。

3.    一次锁定一个表，直到线程得到所有锁定为止。

该规则确保表锁定不会出现死锁定。但是，对于该规则，您需要注意其它的事情：

如果您正在对一个表使用一个LOW_PRIORITY WRITE锁定，这只意味着，MySQL等待特定的锁定，直到没有申请READ锁定的线程时为止。当线程已经获得WRITE锁定，并正在等待得到锁定表清单中的用于下一个表的锁定时，所有其它线程会等待WRITE锁定被释放。如果这成为对于应用程序的严重的问题，则您应该考虑把部分表转化为事务安全型表。

您可以安全地使用KILL来结束一个正在等待表锁定的线程。请参见13.5.5.3节，“KILL语法”。

注意，您不能使用INSERT DELAYED锁定任何您正在使用的表，因为，在这种情况下，INSERT由另一个线程执行。

通常，您不需要锁定表，因为所有的单个UPDATE语句都是原子性的；没有其它的线程可以干扰任何其它当前正在执行的SQL语句。但是，在几种情况下，锁定表会有好处：

·         如果您正在对一组MyISAM表运行许多操作，锁定您正在使用的表，可以快很多。锁定MyISAM表可以加快插入、更新或删除的速度。不利方面是，没有线程可以更新一个用READ锁定的表（包括保持锁定的表），也没有线程可以访问用WRITE锁定的表（除了保持锁定的表以外）。

有些MyISAM操作在LOCK TABLES之下更快的原因是，MySQL不会清空用于已锁定表的关键缓存，直到UNLOCK TABLE被调用为止。通常，关键缓存在每个SQL语句之后被清空。

·         如果您正在使用MySQL中的一个不支持事务的存储引擎，则如果您想要确定在SELECT和UPDATE之间没有其它线程，您必须使用LOCK TABLES。本处所示的例子要求LOCK TABLES，以便安全地执行：

·                mysql> LOCK TABLES trans READ, customer WRITE;
·                mysql> SELECT SUM(value) FROM trans WHERE customer_id=some_id;
·                mysql> UPDATE customer
·                    ->     SET total_value=sum_from_previous_statement
·                    ->     WHERE customer_id=some_id;
·                mysql> UNLOCK TABLES;
如果没有LOCK TABLES，有可能另一个线程会在执行SELECT和UPDATE语句之间在trans表中插入一个新行。

通过使用相对更新（UPDATE customer SET value=value+new_value）或LAST_INSERT_ID()函数，您可以在许多情况下避免使用LOCK TABLES。请参见1.8.5.3节，“事务和原子操作”。

通过使用用户层级的顾问式锁定函数GET_LOCK()和RELEASE_LOCK()，您也可以在有些情况下避免锁定表。这些锁定被保存在服务器中的一个混编表中，使用pthread_mutex_lock() 和pthread_mutex_unlock()，以加快速度。请参见12.9.4节，“其他函数”。

要了解更多有关锁定规则的说明，请参见7.3.1节，“锁定方法”。

您可以使用FLUSH TABLES WITH READ LOCK语句锁定位于所有带有读取锁定的数据库中的所有表。请参见13.5.5.2节，“FLUSH语法”。如果您有一个可以及时拍摄快照的文件系统，比如Veritas，这是获得备份的一个非常方便的方式。

注释：如果您对一个已锁定的表使用ALTER TABLE，该表可能会解锁。请参见A.7.1节，“与ALTER TABLE有关的问题”。

13.4.6. SET TRANSACTION语法
SET [GLOBAL | SESSION] TRANSACTION ISOLATION LEVEL
{ READ UNCOMMITTED | READ COMMITTED | REPEATABLE READ | SERIALIZABLE }
本语句用于设置事务隔离等级，用于下一个事务，或者用于当前会话。

在默认情况下，SET TRANSACTION会为下一个事务（还未开始）设置隔离等级。如果您使用GLOBAL关键词，则语句会设置全局性的默认事务等级，用于从该点以后创建的所有新连接。原有的连接不受影响。要进行此操作，您需要SUPER权限。使用SESSION关键测可以设置默认事务等级，用于对当前连接执行的所有将来事务。

要了解对每个InnoDB事务隔离等级的描述，请参见15.2.10.3节，“InnoDB和TRANSACTION ISOLATION LEVEL”。InnoDB支持MySQL 5.1中的各个等级。默认的等级是REPEATABLE READ。

您可以使用--transaction-isolation选项，对mysqld设置初始的默认全局隔离等级。请参见5.3.1节，“mysqld命令行选项”。

XA事务支持限于InnoDB存储引擎。

MySQL XA实施是针对外部XA的，其中，MySQL服务器作为资源管理器，而客户端程序作为事务管理器。未实施“内部XA”。这样，就允许MySQL服务器内的单独存储引擎作为RM（资源管理器），而服务器本身作为TM（事务管理器）。处理包含1个以上存储引擎的XA事务时，需要内部XA。内部XA的实施是不完整的，这是因为，它要求存储引擎在表处理程序层面上支持两阶段提交，目前仅对InnoDB实现了该特性。

对于XA START，不支持JOIN和RESUME子句。

对于InnoDB存储引擎，可以获得对XA事务的支持。MySQL XA的执行依据X/Open CAE文件Distributed Transaction Processing: The XA Specification。本文件由Open Group出版，可以从http://www.opengroup.org/public/pubs/catalog/c193.htm获取。在I.5节，“对XA事务的限制”对当前XA执行的限制进行了描述。

在客户端方面，没有特殊要求。连接MySQL服务器的XA接口由以XA关键词开头的SQL语句组成。MySQL客户端必须能发送SQL语句，并能理解XA语句接口的语义，但是它们不需要被链接到特定的MySQL客户库上。

当前，在MySQL连接器当中，MySQL连接器/J 5.0.0直接支持XA（也就是，通过一个可以控制XA SQL语句接口的等级接口）。

XA支持分布式的事务，具备能力，让多个独立的事务资源参加全局的事务。事务资源通常是RDBMSs，不过也可以是其它种类的资源。

一个全局事务会涉及到多个行动，这些行动本身是事务性的。不过，所有行动都必须作为一个群组成功完成，或者作为一个群组被回滚。实际上，这会延伸ACID性质，“提高等级”，这样，多个ACID事务就可以一起执行，相当于也拥有ACID性质的全局操作的组件。（但是，对于一个分布式事务，您必须使用SERAILIZABLE隔离等级，以实现ACID性质。对于一个非分布式事务，使用REPEATABLE READ就足够了。但是对于分布式事务，使用REPEATABLE READ是不够的。）

分布式事务的部分示例：

·         应用程序相当于一个把消息传递服务和RDBMS组合在一起的整合工具。应用程序可以确保，所有进行消息发送、回收和处理的事务（同时包含一个事务数据库）均在一个全局事务中发生。您可以把这看作是“事务电子邮件。”

·         应用程序执行的行动会涉及到不同数据库服务器，比如MySQL服务器和Oracle服务器（或多个MySQL服务器）。涉及到多个服务器的行动必须作为一个全局事务的一部分发生，而不是作为针对每个服务器的独立的本地事务发生。

·         银行把帐户信息保存在RDBMS中，并通过自动取款机（ATMs）分发和收取欠款。必须要确保ATM行动被正确地反映到帐户中，但是这不能只由RDBMS单独完成。全局事务管理器会整合ATM和数据库资源，以确保财务事务的整体一致性。

使用全局事务的应用程序涉及一个或多个资源管理器和一个事务管理器：

·         资源管理器（RM）用于提供通向事务资源的途径。数据库服务器是一种资源管理器。该管理器必须可以提交或 回滚由RM管理的事务。

·         事务管理器（TM）用于协调作为一个全局事务一部分的事务。TM与管理每个事务的RMs进行通讯。一个全局事务中各个单个事务均是全局事务的“分支”。全局事务和各分支通过一种命名方法进行标识。这种命名方法在后面进行讲述。

MySQL执行XA MySQL时，MySQL服务器相当于一个用于管理全局事务中的XA事务的资源管理器。与MySQL服务器连接的客户端相当于事务管理器。

要执行一个全局事务，必须知道涉及到了哪些组件，并且把每个组件引到一点，在此时，组件可以被提交或回滚时。根据每个组件报告的有关组件效能的内容，这些组件必须作为一个原子性群组全部提交或 回滚。即，要么所有的组件必须提交，要么所有的组件必须回滚。要管理一个全局事务，必须要考虑任何组件或连接网络可能会故障。

用于执行全局事务的过程使用两阶段提交（2PC），发生时间在由全局事务的分支进行的行动已经被执行之后。

1.    在第一阶段，所有的分支被预备好。即，它们被TM告知要准备提交。通常，这意味着用于管理分支的每个RM会记录对于被稳定保存的分支的行动。分支指示是否它们可以这么做。这些结果被用于第二阶段。

2.    在第二阶段，TM告知RMs是否要提交或 回滚。如果在预备分支时，所有的分支指示它们将能够提交，则所有的分支被告知要提交。如果在预备时，有任何分支指示它将不能提交，则所有分支被告知 回滚。

在有些情况下，一个全局事务可能会使用一阶段提交（1PC）。例如，当一个事务管理器发现，一个全局事务只由一个事务资源组成（即，单一分支），则该资源可以被告知同时进行预备和提交。

13.4.7.1. XA事务SQL语法
要在MySQL中执行XA事务，应使用以下语句：

XA {START|BEGIN} xid [JOIN|RESUME]
 
XA END xid [SUSPEND [FOR MIGRATE]]
 
XA PREPARE xid
 
XA COMMIT xid [ONE PHASE]
 
XA ROLLBACK xid
 
XA RECOVER
对于XA START，JOIN和RESUME子句不被支持。

对于XA END，SUSPEND [FOR MIGRATE]子句不被支持。

每个XA语句以XA关键词为开头，多数语句要求一个xid值。 xid是一个XA事务标识符。它指示该语句适用于哪个事务。xid值由客户端提供，或由MySQL服务器生成。xid值包含一到三个部分：

xid: gtrid [, bqual [, formatID ]]
gtrid是一个全局事务标识符，bqual是一个分支限定符，formatID是一个数字，用于标识由gtrid和bqual值使用的格式。根据语法的表示，bqual和formatID是自选的。如果没有给定，默认的bqual值是''。如果没有给定，默认的fromatID值是1。

gtrid和bqual必须为字符串文字，每个的长度最多为64字节（不是字符）。gtrid和bqual可以用多种方法指定。您可以使用带引号的字符串('ab')，十六进制字符串(0x6162, X'ab')，或位值(b'nnnn')。

formatID是一个无符号的整数。

通过MySQL服务器的带下划线的XA支持子程序，gtrid和bqual值被理解为以字节为单位。但是，在包含XA语句的SQL语句正在被分析的同时，服务器会去操作一些特定的字符集。为了安全，把gtrid和bqual作为十六进制字符串写入。

通常，xid值由事务管理器生成。由一个TM生成的值必须与由其它TMs生成的值不同。一个给定的TM必须能识别自己的xid值。这些值位于由XA RECOVER语句返回的值清单中。

XA START xid用于启动一个带给定xid值的XA事务。每个XA事务必须有一个唯一的xid值，因此该值当前不能被其它的XA事务使用。使用gtrid和bqual值评估唯一性。所有下列的用于XA事务的XA语句必须使用与XA START语句中给定的相同的xid值进行指定。如果您使用这些语句，但是指定的xid值与部分原有的XA事务不对应的话，会发生错误。

一项或多项XA事务可以是同一个全局事务的一部分。在一个给定的全局事务中的所有XA事务必须在xid值中使用同样的gtrid值。出于这个原因，gtrid值必须为全局唯一的，这样，有关一个给定的XA事务是哪个全局事务的一部分的问题就不会含糊不清。对于一个全局事务中的每个XA事务，xid值中的bqual部分必须不一样。（bqual值应不一样，这个要求是当前执行MySQL XA的一个限制条件。这不是XA规约的一部分。）

对于在MySQL服务器上的处于PREPARED状态的XA事务，XA RECOVER语句会返回信息。（见13.4.7.2节，“XA事务状态”.。）输出包括一个行，该行用于服务器上的每个这类XA事务，不论是哪个客户端启动了它。

XA RECOVER输出行看上去像这样（例如，xid值包括'abc', 'def'和 7等部分）：

mysql> XA RECOVER;
+----------+--------------+--------------+--------+
| formatID | gtrid_length | bqual_length | data   |
+----------+--------------+--------------+--------+
|        7 |            3 |            3 | abcdef |
+----------+--------------+--------------+--------+
输出列有以下意义：

·         formatID是事务xid的formatID部分

·         gtrid_length是xid的gtrid部分的长度，以字节为单位

·         bqual_length是xid的bqual部分的长度，以字节为单位

·         data是xid的gtrid部分和bqual部分的串联

XA事务状态
XA事务在以下状态下进展：
1.    使用XA START来启动一个XA事务，并把它放入ACTIVE状态。

2.    对于一个ACTIVE XA事务，发布构成事务的SQL语句，然后发布一个XA END语句。XA END把事务放入IDLE状态。

3.    对于一个IDLE XA事务，您可以发布一个XA PREPARE语句或一个XA COMMIT…ONE PHASE语句：

·         XA PREPARE把事务放入PREPARED状态。在此点上的XA RECOVER语句将在其输出中包括事务的xid值，因为XA RECOVER会列出处于PREPARED状态的所有XA事务。

·         XA COMMIT…ONE PHASE用于预备和提交事务。xid值将不会被XA RECOVER列出，因为事务终止。

4.    对于一个PREPARED XA事务，您可以发布一个XA COMMIT语句来提交和终止事务，或者发布XA ROLLBACK来回滚并终止事务。

下面是一个简单的XA事务，该事务把一行作为一个全局事务的一部分插入一个表中。

mysql> XA START 'xatest';
Query OK, 0 rows affected (0.00 sec)
 
mysql> INSERT INTO mytable (i) VALUES(10);
Query OK, 1 row affected (0.04 sec)
 
mysql> XA END 'xatest';
Query OK, 0 rows affected (0.00 sec)
 
mysql> XA PREPARE 'xatest';
Query OK, 0 rows affected (0.00 sec)
 
mysql> XA COMMIT 'xatest';
Query OK, 0 rows affected (0.00 sec)
根据一个给定的客户端连接的语境，XA事务和本地（非XA）事务互相排斥。举例说明，如果已经发布了XA START来开始一项XA事务，则本地事务不会被启动，直到XA事务已经被提交或被 回滚为止。相反的，如果已经使用START TRANSACTION启动一个本地事务，则XA语句不能被使用，直到该事务被提交或被 回滚为止。

对XA事务的限制
XA事务支持限于InnoDB存储引擎。

MySQL XA实施是针对外部XA的，其中，MySQL服务器作为资源管理器，而客户端程序作为事务管理器。未实施“内部XA”。这样，就允许MySQL服务器内的单独存储引擎作为RM（资源管理器），而服务器本身作为TM（事务管理器）。处理包含1个以上存储引擎的XA事务时，需要内部XA。内部XA的实施是不完整的，这是因为，它要求存储引擎在表处理程序层面上支持两阶段提交，目前仅对InnoDB实现了该特性。

对于XA START，不支持JOIN和RESUME子句。

对于XA END，不支持SUSPEND [FOR MIGRATE]子句。

在全局事务内，对于每个XA事务，xid值的bqual部分应是不同的，该要求是对当前MySQL XA实施的限制。它不是XA规范的组成部分。

如果XA事务达到PREPARED状态而且MySQL服务器宕机，当服务器重启后，能够继续处理事务。就像原本应当的那样。但是，如果客户端连接中止而服务器继续运行，服务器将回滚任何未完成的XA事务，即使该事务已达到PREPARED状态也同样。它应能提交或回滚PREPARED XA事务，但在不更改二进制日志机制的情况下不能这样。

--------------------------------------------------------------------------------

这是MySQL参考手册的翻译版本，关于MySQL参考手册，请访问dev.mysql.com。原始参考手册为英文版，与英文版参考手册相比，本翻译版可能不是最新的。