MySQL的事务
一、事务的概念
在MySQL中，只有InnoDB存储引擎才支持事务。
事务的处理用来维护数据库数据的完整性，保证同一个事务里的一批SQL语句，要么全部执行，要么全部不执行。
事务用来管理DDL、DML、DCL操作，比如insert、update、delete语句，默认自动提交，即执行SQL语句后会马上执行commit操作。
显示地开启一个事务必须使用命令begin或者start transaction，或者执行命令set autocommit=0，用来禁止使用当前会话的自动提交。
- BEGIN或START TRANSACTION：显示地开启一个事务。
- COMMIT：提交事务，并使已数据库进行的所有修改是永久的。
- ROLLBACK：回滚，结束用户的事务，并撤销正在进行的所有未提交的修改。
二、事务的并发问题
在事务的并发操作中可能会出现如下的问题：
- 丢失更新：一个事务更新之后，另外一个事务也对这个数据进行了更新，那么第一个事务的更新就丢失了。
- 脏读：一个事务读取到了另外一个事务未提交的数据
- 不可重复读：一个事务因读取到另外一个事务已经提交的数据。导致对同一条记录的读取两次以上的结果不一致。update操作。
- 幻读：一个事务因读取到另外一个事务已提交的数据，导致对同一张表的读取结果不一致，insert、delete所致。
三、事务的隔离级别
3.1 事务的隔离级别
为了避免以上几种情况的出现，在标准的SQL规范中，定义了4个事务隔离级别，不同隔离级别对事务的处理不同：
四种隔离级别由低到高分别为：
- Read uncommitted(读未提交):最低隔离界别，任何情况都无法保障
- Read committed（读已提交）：可避免脏读发生
- Repeated read（可重复读）：可避免脏读和不可重复读的发生。Innodb的RR还可以解决幻读，主要原因是GAP锁（间隙锁），只有RR才能使用GAP锁。
- serializable(串行化)：可避免所有情况（MVCC降低为Locaking-Base CC）
3.2 默认隔离级别
大多数数据库的默认隔离级别是Read committed，比如Oracle和DB2等。MySQL数据库的默认隔离级别是Repeatable Read。
在MySQL数据库中查看当前事务的隔离级别：
select @@tx_isolation;
在MySQL中设置事务的隔离级别：
set [glogal|session]transaction isolation level 隔离级别名称;
或者
set tx_isolation='隔离级别名称';
隔离级别越高，越能保障数据的一致性和完整性，但是对并发性能的影响也越大。
对于多数的应用程序，可以把默认隔离级别设置为Read Committed，为避免脏读读取，同时还具有良好的并发性能。在可能出现不可重复读、幻读这些问题的场合，可以由应用程序采用悲观
锁或者乐观锁来控制。
3.3 Mysql的事务流程
以update为例，innodb的事务流程如下：
update upms_user set real_name='测试'where user_name='A001';
1）事务开始
2）对user_name='A001'这条数据上排他锁，并对数据两边临近范围加gap锁，防止别的事务insert新数据，保证隔离性。
3）将需要修改的数据页加载到innodb_buffer_cache中（内存中的一块区域）。
4）记录检索数据到undo log（修改前的数据，用来保证数据的原子性和一致性）。
5）修改user_name='A001'的数据real_name='测试'。记录修改数据信息到redo log（注意，是数据的当前页修改操作信息，而不是修改后的数据，用来保证持久性），redo log处于prepare状态，随时可以提交事务。
6）刷新innodb_buffer_cache中脏数据到底层磁盘，非commit触发，数据库自动操作。
7）记录binlog，写入磁盘。
8）提交事务，把刚才的redo log改提交状态（两阶段提交）
9）事务结束
四、事务日志文件
4.1 undo log
undo用来保存数据更改之前的数据；保证原子性、一致性。InnoDB存储引擎中，还用Undo log来实现多版本并发控制（MVCC）。
undo log的目的就是满足事务的原子性。操作任何数据之前，首先将数据备份到undo log，然后进行数据的修改。
undo log是为了解决回滚问题，如果出现了错误或者用户执行了ROLLBACK语句，系统可以利用undo log中的备份将数据恢复到事务开始之前的状态。
4.2 redo log
数据库先写redo logo，然后才修改buffer cache中的页（修改数据），修改是以页为单位的，所以先写redo才能保证一个大事务commit的时候，redo已经刷新的差不多了。反过来说假如是先改buffer cache中的页，然后再写redo，就可能会由很多redo需要写，因为一个页中可能有很多数据行，而很多数据行产生的redo也可能比较多，那么commit的时候，就可能会有很多redo需要写。
在事务提交前，只需要将redo log持久化即可。不需要将数据持久化，当系统崩溃时，虽然数据没有持久化，但是Redo log已经持久化。系统可以根据redo log的内容，将所有的数据恢复到最新的状态。需要注意的是，事务过程中，先把redo写进redo log buffer中，然后MySQL后台进程page cleaner thread适当的去刷新redo到底层磁盘永久保存。