Mysql事务

MySQL事务

    什么是事务

    事务的四大特性

    MySQL的事务

事务隔离级别

    并发常见问题

    四大隔离级别

编码中的事务

事务的分类

事务的实现

    redo

    undo

    purge

    group commit

事务的控制语句

mysql事务

什么是事务

 事务（transaction）是数据库区别于文件系统的重要特性之一。

    银行转账！张三转10000块到李四的账户，这其实需要两条SQL语句：

    l 给张三的账户减去10000元；

    l 给李四的账户加上10000元。

    如果在第一条SQL语句执行成功后，在执行第二条SQL语句之前，程序被中断了（可能是抛出了某个异常，也可能是其他什么原因），那么李四的账户没有加上10000元，而张三却减去了10000元。这肯定是不行的！

    你现在可能已经知道什么是事务了吧！事务中的多个操作，要么完全成功，要么完全失败！不可能存在成功一半的情况！也就是说给张三的账户减去10000元如果成功了，那么给李四的账户加上10000元的操作也必须是成功的；否则给张三减去10000元，以及给李四加上10000元都是失败的！

    事务的四大特性（ACID）

    事务的四大特性是：

    l 原子性（Atomicity）：事务中所有操作是不可再分割的原子单位。事务中所有操作要么全部执行成功，要么全部执行失败。

    l 一致性（Consistency）：事务执行后，数据库状态与其它业务规则保持一致。如转账业务，无论事务执行成功与否，参与转账的两个账号余额之和应该是不变的。

    l 隔离性（Isolation）：隔离性是指在并发操作中，不同事务之间应该隔离开来，使每个并发中的事务不会相互干扰。

    l 持久性（Durability）：一旦事务提交成功，事务中所有的数据操作都必须被持久化到数据库中，即使提交事务后，数据库马上崩溃，在数据库重启时，也必须能保证通过某种机制恢复数据。

    MySQL中的事务

    在默认情况下，MySQL每执行一条SQL语句，都是一个单独的事务。如果需要在一个事务中包含多条SQL语句，那么需要开启事务和结束事务。

    l 开启事务：start transaction；

    l 结束事务：commit或rollback。

    在执行SQL语句之前，先执行strat transaction，这就开启了一个事务（事务的起点），然后可以去执行多条SQL语句，最后要结束事务，commit表示提交，即事务中的多条SQL语句所做出的影响会持久化到数据库中。或者rollback，表示回滚，即回滚到事务的起点，之前做的所有操作都被撤消了！

事务隔离级别

并发事务问题

因为并发事务导致的问题大致有5类，其中两类是更新问题，三类是读问题。

l 脏读（dirty read）：读到另一个事务的未提交更新数据，即读取到了脏数据；

l 不可重复读（unrepeatable read）：对同一记录的两次读取不一致，因为另一事务对该记录做了修改；

l 幻读（虚读）（phantom read）：对同一张表的两次查询不一致，因为另一事务插入了一条记录；

不可重复读和幻读的区别：

l 不可重复读是读取到了另一事务的更新；

l 幻读是读取到了另一事务的插入（MySQL中无法测试到幻读）；

四大隔离级别

4个等级的事务隔离级别，在相同数据环境下，使用相同的输入，执行相同的工作，根据不同的隔离级别，可以导致不同的结果。不同事务隔离级别能够解决的数据并发问题的能力是不同的。

1SERIALIZABLE（串行化）

l 不会出现任何并发问题，因为它是对同一数据的访问是串行的，非并发访问的；

l 性能最差；

2REPEATABLE READ（可重复读）（MySQL）

l 防止脏读和不可重复读，不能处理幻读问题；

l 性能比SERIALIZABLE好

3READ COMMITTED（读已提交数据）（Oracle）

l 防止脏读，没有处理不可重复读，也没有处理幻读；

l 性能比REPEATABLE READ好

4READ UNCOMMITTED（读未提交数据）

l 可能出现任何事务并发问题

l 性能最好

MySQL隔离级别

MySQL的默认隔离级别为Repeatable read，可以通过下面语句查看：

也可以通过下面语句来设置当前连接的隔离级别：

编码中的事务

    重点： 事务的理解

    在代码开发中，业务逻辑类中的每一个public方法，都可以看成是一个事务 ！

    业务逻辑层中的每一个public方法，都是一个交易

    强调： 事务操作中的多个步骤，这些必须要使用同一个connection对象,否则无法进行事务控制

事务的分类

本地事务(local transaction) :  事务管理器控制本地资源（数据库资源，消息中间件资源）

XA事务 （二段提交） ：又叫JTA， 可以管理两个系统的资源 ，两段提交，两个资源不一定在本地

    可以是两个数据库系统，也可以是一个数据库+消息中间件。

    TUXEDO(BEA公司) -->> WebLogic ,  EJB

声明式事务：spring

分布式事务：  BASE, MOM(异步通讯)

事务的实现

redo log称为重做日志，用来保证事务的原子性和持久性。undo log用来保证事务的一致性。

一、redo

基本概念

    其由两部分组成：一是内存中的重做日志缓冲，其是易丢失的；而是重做日志文件、其是持久的。

    每个InnoDB 存储引擎至少有1 个重做日志文件组（group），每个文件组下至少有2 个重做日志文件，如默认的ib_logfile0 和ib_logfile1。为了得到更高的可靠性，用户可以设置多个的镜像日志组（mirrored log groups），将不同的文件组放在不同的磁盘上，以此提高重做日志的高可用性。在日志组中每个重做日志文件的大小一致，并以循环写入的方式运行。InnoDB 存储引擎先写重做日志文件1，当达到文件的最后时，会切换至重做日志文件2，再当重做日志文件2 也被写满时，会再切换到重做日志文件1 中。

    下列参数影响着重做日志文件的属性：

• innodb_log_file_size

• innodb_log_files_in_group

• innodb_mirrored_log_groups

• innodb_log_group_home_dir

参数innodb_log_file_size 指定每个重做日志文件的大小。在InnoDB1.2.x 版本之前，重做日志文件总的大小不得大于等于4GB，而1.2.x 版本将该限制扩大为了512GB。

参数innodb_log_files_in_group 指定了日志文件组中重做日志文件的数量，默认为2。

参数innodb_mirrored_log_groups 指定了日志镜像文件组的数量，默认为1，表示只有一个日志文件组，没有镜像。

    重做日志文件的大小设置对于InnoDB 存储引擎的性能有着非常大的影响。一方面重做日志文件不能设置得太大，如果设置得很大，在恢复时可能需要很长的时间；另一方面又不能设置得太小了，否则可能导致一个事务的日志需要多次切换重做日志文件。此外，重做日志文件太小会导致频繁地发生async checkpoint，导致性能的抖动。

也许有人会问，既然同样是记录事务日志，和之前介绍的二进制日志有什么区别？

    首先，二进制日志会记录所有与MySQL 数据库有关的日志记录，包括InnoDB、MyISAM、Heap 等其他存储引擎的日志。而InnoDB 存储引擎的重做日志只记录有关该存储引擎本身的事务日志。

    其次，记录的内容不同，无论用户将二进制日志文件记录的格式设为STATEMENT还是ROW，又或者是MIXED，其记录的都是关于一个事务的具体操作内容，即该日志是逻辑日志。而InnoDB 存储引擎的重做日志文件记录的是关于每个页（Page）的更改的物理情况。

    此外，写入的时间也不同，二进制日志文件仅在事务提交前进行提交，即只写磁盘一次，不论这时该事务多大。而在事务进行的过程中，却不断有重做日志条目（redoentry）被写入到重做日志文件中。

在InnoDB 存储引擎中，对于各种不同的操作有着不同的重做日志格式。到InnoDB1.2.x 版本为止，总共定义了51 种重做日志类型。虽然各种重做日志的类型不同，但是它们有着基本的格式：

写入重做日志文件的操作不是直接写，而是先写入一个重做日志缓冲（redo log buffer）中，然后按照一定的条件顺序地写入日志文件。

从重做日志缓冲往磁盘写入时，是按512 个字节，也就是一个扇区的大小进行写入。因为扇区是写入的最小单位，因此可以保证写入必定是成功的。因此在重做日志的写入过程中不需要有doublewrite。

    主线程（master thread），知道在主线程中每秒会将重做日志缓冲写入磁盘的重做日志文件中，不论事务是否已经提交。另一个触发写磁盘的过程是由参数innodb_flush_log_at_trx_commit 控制，表示在提交（commit）操作时，处理重做日志的方式。

    参数innodb_flush_log_at_trx_commit 的有效值有0、1、2。0 代表当提交事务时，并不将事务的重做日志写入磁盘上的日志文件，而是等待主线程每秒的刷新。1 和2 不同的地方在于：1 表示在执行commit 时将重做日志缓冲同步写到磁盘，即伴有fsync 的调用。2 表示将重做日志异步写到磁盘，即写到文件系统的缓存中。因此不能完全保证在执行commit 时肯定会写入重做日志文件，只是有这个动作发生。

    因此为了保证事务的ACID 中的持久性，必须将innodb_flush_log_at_trx_commit 设置为1，也就是每当有事务提交时，就必须确保事务都已经写入重做日志文件。那么当数据库因为意外发生宕机时，可以通过重做日志文件恢复，并保证可以恢复已经提交的事务。而将重做日志文件设置为0 或2，都有可能发生恢复时部分事务的丢失。不同之处在于，设置为2 时，当MySQL 数据库发生宕机而操作系统及服务器并没有发生宕机时，由于此时未写入磁盘的事务日志保存在文件系统缓存中，当恢复时同样能保证数据不丢失。

二、undo

Undolog:在操作任何数据之前，首先将数据备份到一个地方（undolog），然后再修改；这样就算更改到一半的时候，出现意外更改没有完成，则还可以恢复原来数据。

undo log格式：insert undo log、update undo log；

三、purge

四、group commit

本文转自 叫我北北 51CTO博客，原文链接:http://blog.51cto.com/qinbin/1931089