MySQL--最全事务总结

概念

一组SQL语句（一组原子性的SQL查询），要么完整执行，要么都不执行。

例子：

使用（事务控制）

使用SHOW VARIABLES LIKE 'AUTOCOMMIT'查询，通过SET AUTOCOMMIT=0|1关闭或打开。

默认情况下，MySQL 是自动提交（Autocommit）的，如果需要通过明确的 Commit 和
Rollback 来提交和回滚事务，那么需要通过明确的事务控制命令来开始事务，这是和 Oracle
的事务管理明显不同的地方。如果应用是从 Oracle 数据库迁移到 MySQL 数据库，则需要确
保应用中是否对事务进行了明确的管理。
 START TRANSACTION 或 BEGIN 语句可以开始一项新的事务。
 COMMIT 和 ROLLBACK 用来提交或者回滚事务。
 CHAIN 和 RELEASE 子句分别用来定义在事务提交或者回滚之后的操作，CHAIN 会即启动一个新事物，并且和刚才的事务具有相同的隔离级别，RELEASE 则会断开和客户端的连接。
 SET AUTOCOMMIT 可以修改当前连接的提交方式，如果设置了 SET AUTOCOMMIT=0，则设置之后的所有事务都需要通过明确的命令进行提交或者回滚。

如果只是对某些语句需要进行事务控制，则使用 START TRANSACTION 语句开始一个事务比较方便，这样事务结束之后可以自动回到自动提交的方式；

如果希望所有的事务都不是自动提交的，那么通过修改 AUTOCOMMIT 来控制事务比较方便，这样不用在每个事务开始的时候再执行 START TRANSACTION 语句；

如果在提交的时候使用 COMMIT AND CHAIN，那么会在提交后立即开始一个新的事务，不用在每个事务开始的时候再执行 START TRANSACTION 语句；

隐含提交：即提交（写或保存）操作是自动进行的。一般的MySQL语句都是直接针对数据库表执行和编写的。

隐含事务关闭

当COMMIT或ROLLBACK语句执行后，事务会自动关闭（将来的更改会隐含提交）。

回退

ROLLBACK命令用来回退（撤销） MySQL语句，只能在一个事务处理内使用。

哪些语句可以回退？
事务处理用来管理INSERT、 UPDATE和DELETE语句。你不能回退SELECT语句。（这样做也没有什么意义。）你不能回退CREATE或DROP操作。事务处理块中可以使用这两条语句，但如果你执行回退，它们不会被撤销。]

使用保留点

为了支持回退部分事务处理，必须能在事务处理块中合适的位置放置占位符。这样，如果需要回退，可以回退到某个占位符。
这些占位符称为保留点。可以在MySQL代码中设置任意多的保留点，越多越好。
创建占位符 SAVEPOINT delete1; 回退到保留点 ROLLBACK TO delete1;

释放保留点

保留点在事务处理完成（执行一条ROLLBACK或COMMIT）后自动释放。自MySQL 5以来，也可以用RELEASE SAVEPOINT明确地释放保留点。

分布式事务

使用分布式事务的应用程序涉及一个或多个资源管理器和一个事务管理器。

资源管理器（RM）用于提供通向事务资源的途径。数据库服务器是一种资源管理器。该管理器必须可以提交或回滚由 RM 管理的事务。
事务管理器（TM）用于协调作为一个分布式事务一部分的事务。TM 与管理每个事务的 RMs 进行通讯。一个分布式事务中各个单个事务均是分布式事务的“分支事务”。

原理

要执行一个分布式事务，必须知道这个分布式事务涉及到了哪些资源管理器，并且把每个资源管理器的事务执行到事务可以被提交或回滚时。根据每个资源管理器报告的有关执行情况的内容，这些分支事务必须作为一个原子性操作全部提交或回滚。

用于执行分布式事务的过程使用两阶段提交，发生时间在由分布式事务的各个分支需要进行的行动已经被执行之后。
 在第一阶段，所有的分支被预备好。即它们被 TM 告知要准备提交。通常，这意味着用于管理分支的每个 RM 会记录对于被稳定保存的分支的行动。分支指示是否它们可以这么做。这些结果被用于第二阶段。
 在第二阶段，TM 告知 RMs 是否要提交或回滚。如果在预备分支时，所有的分支指示它们将能够提交，则所有的分支被告知要提交。如果在预备时，有任何分支指示它将不能提交，则所有分支被告知回滚。

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

分布式事务（XA 事务）的 SQL 语法
启动

XA {START|BEGIN} xid [JOIN|RESUME] （xid: gtrid [, bqual [, formatID ]]）

使事务进入 PREPARE 状态，也就是两阶段提交的第一个提交阶段
XA END xid [SUSPEND [FOR MIGRATE]]
XA PREPARE xid
用来提交或者回滚具体的分支事务。也就是两阶段提交的第二个提交阶段，分支事务被实际的提交或者回滚。

XA COMMIT xid [ONE PHASE]
XA ROLLBACK xid
XA RECOVER 返回当前数据库中处于 PREPARE 状态的分支事务的详细信息。
存在的问题
如果分支事务在达到 prepare 状态时，数据库异常重新启动，服务器重新启动以后，可以继续对分支事务进行提交或者回滚得操作，但是提交的事务没有写 binlog，存在一定的隐患，可能导致使用 binlog 恢复丢失部分数据。如果存在复制的数据库，则有可能导致主从数据库的数据不一致。
如果分支事务的客户端连接异常中止，那么数据库会自动回滚未完成的分支事务，如果此时分支事务已经执行到 prepare 状态，那么这个分布式事务的其他分支可能已经成功提交，如果这个分支回滚，可能导致分布式事务的不完整，丢失部分分支事务的内容。
如果分支事务在执行到 prepare 状态时，数据库异常，且不能再正常启动，需要使用备份和 binlog 来恢复数据，那么那些在 prepare 状态的分支事务因为并没有记录到 binlog，所以不能通过 binlog 进行恢复，在数据库恢复后，将丢失这部分的数据。

如果应用对事务的完整性有比较高的要求，那么对于当前的版本，则不推荐使用分布式事务。

一个良好的事务处理系统，必须具备ACID四个条件。

原子性（Atomicity，或称不可分割性）、一致性（Consistency）、隔离性（Isolation，又称独立性）、持久性（Durability）。

原子性：一个事务（transaction）中的所有操作，要么全部完成，要么全部不完成，不会结束在中间某个环节。事务在执行过程中发生错误，会被回滚（Rollback）到事务开始前的状态，就像这个事务从来没有执行过一样。
一致性：数据库总是从一个一致性的状态转到另一个一致性的状态。在事务开始之前和事务结束以后，数据库的完整性没有被破坏。这表示写入的资料必须完全符合所有的预设规则，这包含资料的精确度、串联性以及后续数据库可以自发性地完成预定的工作。
隔离性：一个事务所做的修改在最终提交以前，对其他事务不可见。数据库允许多个并发事务同时对其数据进行读写和修改的能力，隔离性可以防止多个事务并发执行时由于交叉执行而导致数据的不一致。事务隔离分为不同级别，包括读未提交（Read uncommitted）、读提交（read committed）、可重复读（repeatable read）和串行化（Serializable）。
持久性：事务处理结束后，对数据的修改就是永久的，即便系统故障也不会丢失。

隔离级别