8.1 事务概述
事务应该满足ACID。（原子性，一致性，隔离性，持久性）;
-
A(atomicity) 原子性：每条语句，或者一个事务，当做一个整体，要么成功，要么失败回滚。事务是一个不可分割的单位。
-
C(consistency) 一致性：事务将数据库从一个状态转变为另外一种一致的状态，数据库的完整性约束不会被改变。 比如表中姓名不能重复,如果事务修改后回滚,表中数据姓名变得非唯一,则破坏了一致性;
-
I(isolation), 隔离性：别称并发控制，可串行化，锁。保证事务提交前其他事务看不见。
-
D(durability)，持久性：凡是提交了的事务，都应该持久化到磁盘上，即使数据库崩溃，也能通过日志来恢复。
8.2 事务的分类
1) 扁平事务
实际生产环境中最频繁的一种事务，所有操作都处于同一层次，要么都执行，要么都回滚;
- 优点：使用简单，广泛使用。
- 缺点：不能提交事务的一部分，或分步骤提交。
2) 带有保存点的扁平事务
除了支持扁平事务外，允许在事务执行的过程中回滚到同一事务中的较早一个状态(保存点savepoint);
当系统发生崩溃时，所有的保存点都将消失，因为其保存点是易失的，而非持久的。
3) 链事务
提交一个事务时，释放不需要的数据对象，将必要的处理上下文隐式的传给下一个要开始的事务。
链式事务只能回滚仅限于当前事务，即只能恢复到最近一个保存点;
4) 嵌套事务
嵌套事务时一个层次结构框架，有一个顶层事务控制着各个层次的事务(子事务);
mysql不是原生的;
保存技术比嵌套查询更灵活;
当使用保存技术,无论持有多少个保存点,所有被锁住的对象都可以被得到和访问;
而嵌套查询中,不同的子事务在数据库对象上持有锁不同;
5) 分布式事务
通常是一个在分布式环境下运行的扁平事务;
8.3 事务控制语句
-
START TRANSATION / BEGIN : 显式开启一个事务;
-
COMMIT 基本= COMMIT WORK
-
ROLLBACK 基本 = ROLLBACK WORK
-
SAVEPOINT xxx : SAVEPOINT允许在事务中创建一个保存点, 一个事务中可以有多个SAVEPOINT;
-
RELEASE SAVEPOINT xxx : 删除一个事务的保存点, 当没有一个保存点执行这个语句时,会抛出异常;
-
ROLLBACK TO [SAVEPOINT] xxx : 可以把事务回滚到标记点,
例如:
update语句1 ------> update语句2 ------> savepoint ------> DELETE语句1 ------> DELETE语句2;
如果执行DELETE语句期间发生异常, 而且捕获到了这个异常,并发出ROLLBACK TO POINT 命令,事务就会回滚到指定的SAVEPOINT,撤销DELETE完成的所有工作, 而update语句完成的工作不受影响。
-
SET TRANSATION: InnoDB提供事务隔离级别有: (READ UNCOMMITTED / READ COMMITTED / REPEATABLE READ / SERIALIZABLE )
在命令行下开启事务可以： BEGIN 。。。 END
或者 START TRANSATION 。。。COMMIT
但是在存储过程中，mysql数据库的分析器会自动的把BEGIN识别为 BEGIN...END，所以在存储过程中只能使用 START TRANSATION
COMMIT 和 COMMIT WORK :
语句基本上是一致的,都是用来提交事务。
不同之处在于 COMMIT WORK 用来控制事务结束后的行为是CHAIN还是RELEASE的;
如果是CHAIN则事务变成链事务;
用户可以用completion_type来进行控制,
默认该参数为0,没有任何操作,这种设置下 COMMIT和COMMIT WORK 完全等价;
completion_type=1, COMMIT WORK 等同于 COMMIT AND CHAIN,表示马上自动开启一个相同隔离级别的事务;
completion_type=2, COMMIT WORK 等同于 COMMIT AND RELEASE, 当事务提交后悔自动断开与服务器的联接 ;
ROLLBACK和ROLLBACK WORK :
与COMMIT 和 COMMIT WORK 的工作一样;
ROLLBACK TO SAVEPOINT :
可以回滚到一个不存在的保存点,会抛出异常;
虽然有rollback 但并没有结束事务, 还需要显式地运行commit或rollback命令;
8.4 隐式提交的SQL语句
8.7 不好的事务编程习惯
8.7.1 在循环中提交
不要在循环中提交。无论是显式提交还是隐式提交。
每一次提交都要写一次redo日志;
8.7.2 使用自动提交
因为不同语言的API的自动提交设置是不一样的，容易出错。
8.7.3 使用自动回滚
最好是在程序中控制事务。
8.8 长事务
长事务: 执行时间较长的事务;
长事务最好分为批量小事务。因为长事务如果失败，回滚的代价太大了。
8.9 小结
-
SET TRANSATION: InnoDB提供事务隔离级别有: (READ UNCOMMITTED / READ COMMITTED / REPEATABLE READ / SERIALIZABLE )
在命令行下开启事务可以： BEGIN 。。。 END
或者 START TRANSATION 。。。COMMIT
但是在存储过程中，mysql数据库的分析器会自动的把BEGIN识别为 BEGIN...END，所以在存储过程中只能使用 START TRANSATION
COMMIT 和 COMMIT WORK :
语句基本上是一致的,都是用来提交事务。
不同之处在于 COMMIT WORK 用来控制事务结束后的行为是CHAIN还是RELEASE的;
如果是CHAIN则事务变成链事务;
用户可以用completion_type来进行控制,
默认该参数为0,没有任何操作,这种设置下 COMMIT和COMMIT WORK 完全等价;
completion_type=1, COMMIT WORK 等同于 COMMIT AND CHAIN,表示马上自动开启一个相同隔离级别的事务;
completion_type=2, COMMIT WORK 等同于 COMMIT AND RELEASE, 当事务提交后悔自动断开与服务器的联接 ;
ROLLBACK和ROLLBACK WORK : 与COMMIT 和 COMMIT WORK 的工作一样;
ROLLBACK TO SAVEPOINT :
可以回滚到一个不存在的保存点,会抛出异常;
虽然有rollback 但并没有结束事务, 还需要显式地运行commit或rollback命令;
8.4 隐式提交的SQL语句
8.5 事务的隔离级别
-
READ UNCOMMITTED
-
READ COMMITTED
-
REPEATABLE READ
-
SERIALIZABLE
InnoDB存储引擎默认支持的隔离级别是 REPEATABLE READ，使用Next-Key Lock的锁算法，避免了幻读的产生。在这个级别下已经可以完全保证事务的安全性。达到SERIALIZABLE的隔离级别，但是性能比其好。
隔离级别越低，事务请求的锁越少或保持锁的时间越短。
SERIALIZABLE :
InnoDB会对每一个select 语句后自动加上LOCK IN SHARE MODE,即 给每个读取操作加一个共享锁, 在这个事务隔离级别下,读占用锁了;
SERIALIZABLE主要用于InnoDB的分布式事务;
READ COMMITTED :
除了唯一性约束检查及外键约束的检查需要Gap lock，InnoDB存储引擎不会使用Gap Lock锁算法。（注意，mysql5.1以前，这个隔离级别只能工作在Replication(复制)的二进制日志为Row格式下。mysql5.1后不会了，也可以工作在STATEMENT格式下。） 最好建议是选择Row格式的二进制日志。因为记录的是行的变更，而不是SQL语句。避免出现主从不同步的现象 ;
事务的并发问题：
-
脏读 (读后数据回滚)：事务A读取了事务B更新的数据，然后B回滚操作，那么A读取到的数据是脏数据
-
不可重复读 (修改导致重复读数据不一致) ：事务 A 多次读取同一数据，事务 B 在事务A多次读取的过程中，对数据作了更新并提交，导致事务A多次读取同一数据时，结果 不一致。
-
幻读：系统管理员A将数据库中所有学生的成绩从具体分数改为ABCDE等级，但是系统管理员B就在这个时候插入了一条具体分数的记录，当系统管理员A改结束后发现还有一条记录没有改过来，就好像发生了幻觉一样，这就叫幻读。
-
小结：不可重复读的和幻读很容易混淆，不可重复读侧重于修改，幻读侧重于新增或删除。
解决不可重复读的问题只需锁住满足条件的行，解决幻读需要锁表
小结:
1、SQL规范所规定的标准，不同的数据库具体的实现可能会有些差异
2、mysql中默认事务隔离级别是可重复读时并不会锁住读取到的行
3、事务隔离级别为读提交时，写数据只会锁住相应的行
4、事务隔离级别为可重复读时，
如果有索引（包括主键索引）的时候，以索引列为条件更新数据，会存在间隙锁、行锁、下一键锁的问题，从而锁住一些行；
如果没有索引，更新数据时会锁住整张表。
5、事务隔离级别为串行化时，读写数据都会锁住整张表
6、隔离级别越高，越能保证数据的完整性和一致性，但是对并发性能的影响也越大，鱼和熊掌不可兼得。对于多数应用程序，可以优先考虑把数据库系统的隔离级别设为Read Committed，它能够避免脏读取，而且具有较好的并发性能。尽管它会导致不可重复读、幻读这些并发问题，在可能出现这类问题的个别场合，可以由应用程序采用悲观锁或乐观锁来控制。
8.6 分布式事务编程
允许多个独立的事务资源参与到一个全局的事务中。全局事务中的事务要么全都成功，要么都回滚。在使用分布式事务时，InnoDB的隔离级别必须是SERIALIZABLE的。 InnoDB支持XA事务，并通过XA事务来支持分布式事务。异构分布式数据库可以通过XA事务实现分布式事务。
XA事务：
-
一个或多个资源管理器（提供访问事务资源的方法,一个数据库就是一个资源管理器）
-
一个事务管理器（协调参与全局事务中的各个事务）
-
一个应用程序（定义事务的边界，指定全局事务中的操作）
分布式事务使用两段提交的方式:
第一阶段,所有参与全局事务的节点都开始准备(prepare),告诉TM, 它们准备好提交了;
第二阶段,TM告诉RM's 执行ROLLBACK或者COMMIT;
如果任何一个节点显示不能提交,则所有节点都被告知需要回滚;
Mysql内部也是通过XA事务来协调两张表的操作,实现原子性的;
8.7 不好的事务编程习惯
8.7.1 在循环中提交
不要在循环中提交。无论是显式提交还是隐式提交。
每一次提交都要写一次redo日志;
8.7.2 使用自动提交
因为不同语言的API的自动提交设置是不一样的，容易出错。
8.7.3 使用自动回滚
最好是在程序中控制事务。
8.8 长事务
长事务: 执行时间较长的事务;
长事务最好分为批量小事务。因为长事务如果失败，回滚的代价太大了。
8.9 小结