mysql的事务管理

在 MySQL 中只有使用了 Innodb 数据库引擎的数据库或表才支持事务。MyISAM引擎支持表级锁而InnoDB支持行级锁

mysql数据库的事务有四大原则：ACID

原子性（Atomicity）：一组事务，要么成功；要么撤回。

稳定性/一致性（Consistency）: 确保数据库正确地改变状态后，成功提交的事务

隔离性（Isolation）: ：事务独立运行。一个事务处理后的结果，影响了其他事务，那么其他事务会撤回。事务的100%隔离，需要牺牲速度。

持久性（Durability）：确保提交的事务的结果或效果的系统出现故障的情况下仍然存在。

隔离原因：

数据库事务会导致脏读、不可重复读和幻影读等问题。 

脏读：事务还没提交，他的修改已经被其他事务看到。 

不可重复读：同一事务中两个相同SQL读取的内容可能不同。两次读取之间其他事务提交了修改可能会造成读取数据不一致。 

幻影数据：同一个事务突然发现他以前没发现的数据。和不可重复读很类似，不过修改数据改成增加数据。 

针对可能的问题，InnoDB提供了四种不同级别的机制保证数据隔离性。 

事务的隔离用是通过锁机制实现的，不同于MyISAM使用表级别的锁，InnoDB采用更细粒度的行级别锁，提高了数据表的性能。InnoDB的锁通过锁定索引来实现，如果查询条件中有主键则锁定主键，如果有索引则先锁定对应索引然后再锁定对应的主键（可能造成死锁），如果连索引都没有则会锁定整个数据表。

隔离级别：

1 READ UNCOMMIT

READ UNCOMMIT允许某个事务看到其他事务并没有提交的数据。可能会导致脏读、不可重复读、幻影数据。 

原理：READ UNCOMMIT不会采用任何锁。

2 READ COMMIT

READ COMMIT允许某个事务看到其他事务已经提交的数据。可能会导致不可重复读和幻影数据。 

原理：数据的读是不加锁的，但是数据的写入、修改、删除加锁，避免了脏读。

3 REPEATABLE READ

InnoDB中REPEATABLE READ级别同一个事务的两次相同读取肯定是一样的，其他事务的提交不会对本次事务有影响。

　　原理：数据的读、写都会加锁，当前事务如果占据了锁，其他事务必须等待本次事务提交完成释放锁后才能对相同的数据行进行操作。

4 SERIALIZABLE

　　SERIALIZABLE 级别在InnoDB中和REPEATABLE READ采用相同的实现。

隔离级别

原子性、稳定性和持久性实现原理

　　原子性、稳定性和持久性是通过redo 和 undo 日志文件实现的，不管是redo还是undo文件都会有一个缓存我们称之为redo_buf和undo_buf。同样，数据库文件也会有缓存称之为data_buf。

1 undo 日志文件

　　undo记录了数据在事务开始之前的值，当事务执行失败或者ROLLBACK时可以通过undo记录的值来恢复数据。例如 AA和BB的初始值分别为3，5。

A ，事务开始

B ，记录AA=3到undo_buf

C，修改AA=1

D，记录BB=5到undo_buf

E，修改BB=7

F ，将undo_buf写到undo(磁盘)

G ，将data_buf写到datafile(磁盘)

H ，事务提交

通过undo可以保证原子性、稳定性和持久性 

如果事务在F之前崩溃由于数据还没写入磁盘，所以数据不会被破坏。 

如果事务在G之前崩溃或者回滚则可以根据undo恢复到初始状态。 

数据在任务提交之前写到磁盘保证了持久性。 

但是单纯使用undo保证原子性和持久性需要在事务提交之前将数据写到磁盘，浪费大量I/O。

2 redo/undo 日志文件

　　引入redo日志记录数据修改后的值，可以避免数据在事务提交之前必须写入到磁盘的需求，减少I/O。

A ，事务开始

B， 记录AA=3到undo_buf

C，修改AA=1记录redo_buf

D，记录BB=5到undo_buf

E，修改BB=7记录redo_buf

F ，将redo_buf写到redo（磁盘）

G ，事务提交

通过undo保证事务的原子性，redo保证持久性。 

F之前崩溃由于所有数据都在内存，恢复后重新冲磁盘载入之前的数据，数据没有被破坏。 

FG之间的崩溃可以使用redo来恢复。 

G之前的回滚都可以使用undo来完成。

Undo + Redo事务的特点

A. 为了保证持久性，必须在事务提交前将Redo Log持久化。

B. 数据不需要在事务提交前写入磁盘，而是缓存在内存中。

C. Redo Log 保证事务的持久性。

D. Undo Log 保证事务的原子性。

E. 有一个隐含的特点，数据必须要晚于redo log写入持久存储。

IO性能

Undo + Redo的设计主要考虑的是提升IO性能。虽说通过缓存数据，减少了写数据的IO.

但是却引入了新的IO，即写Redo Log的IO。如果Redo Log的IO性能不好，就不能起到提高性能的目的。

为了保证Redo Log能够有比较好的IO性能，InnoDB 的 Redo Log的设计有以下几个特点：

A. 尽量保持Redo Log存储在一段连续的空间上。因此在系统第一次启动时就会将日志文件的空间完全分配。

以顺序追加的方式记录Redo Log,通过顺序IO来改善性能。

B. 批量写入日志。日志并不是直接写入文件，而是先写入redo log buffer.当需要将日志刷新到磁盘时

(如事务提交),将许多日志一起写入磁盘.

C. 并发的事务共享Redo Log的存储空间，它们的Redo Log按语句的执行顺序，依次交替的记录在一起，

以减少日志占用的空间。例如,Redo Log中的记录内容可能是这样的：

记录1:<trx1, insert …>

记录2:<rx1,update …>

D. 因为C的原因,当一个事务将Redo Log写入磁盘时，也会将其他未提交的事务的日志写入磁盘。

E. Redo Log上只进行顺序追加的操作，当一个事务需要回滚时，它的Redo Log记录也不会从

Redo Log中删除掉。

恢复(Recovery)

- 恢复策略

前面说到未提交的事务和回滚了的事务也会记录Redo Log，因此在进行恢复时,这些事务要进行特殊的

的处理.有2中不同的恢复策略：

A. 进行恢复时，只重做已经提交了的事务。

B. 进行恢复时，重做所有事务包括未提交的事务和回滚了的事务。然后通过Undo Log回滚那些

未提交的事务。

InnoDB存储引擎的恢复机制

MySQL数据库InnoDB存储引擎使用了B策略, InnoDB存储引擎中的恢复机制有几个特点：

A. 在重做Redo Log时，并不关心事务性。 恢复时，没有BEGIN，也没有COMMIT,ROLLBACK的行为。

也不关心每个日志是哪个事务的。尽管事务ID等事务相关的内容会记入Redo Log，这些内容只是被当作

要操作的数据的一部分。

B. 使用B策略就必须要将Undo Log持久化，而且必须要在写Redo Log之前将对应的Undo Log写入磁盘。

Undo和Redo Log的这种关联，使得持久化变得复杂起来。为了降低复杂度，InnoDB将Undo Log看作

数据，因此记录Undo Log的操作也会记录到redo log中。这样undo log就可以象数据一样缓存起来，

而不用在redo log之前写入磁盘了。

包含Undo Log操作的Redo Log，看起来是这样的：

记录1: <trx1,Undo log insert<undo_insert......>>

记录2:<trx1,insert........>

C. 到这里，还有一个问题没有弄清楚。既然Redo没有事务性，那岂不是会重新执行被回滚了的事务？

确实是这样。同时Innodb也会将事务回滚时的操作也记录到redo log中。回滚操作本质上也是

对数据进行修改，因此回滚时对数据的操作也会记录到Redo Log中。

一个回滚了的事务的Redo Log，看起来是这样的：

记录1: <trx1, undo log insert<undo_insert A>>

记录2: <trx1, insert A…>

记录3: <trx1,undo log update<undo_update B>>

记录4: <trx1, update B…>

记录5: <trx1, undo log delete <undo_delete C>>

记录6: <trx1, delete C…>

记录7: <trx1, insert C>

记录8: <trx1, update B to old value>

记录9: <trx1, delete A>

一个被回滚了的事务在恢复时的操作就是先redo再undo，因此不会破坏数据的一致性.

InnoDB存储引擎中相关的函数

Redo: recv_recovery_from_checkpoint_start()

Undo: recv_recovery_rollback_active()

Undo Log的Redo Log: trx_undof_page_add_undo_rec_log()

事务操作命令

如果需要使用事务就必须选用支持事务的数据库引擎如InnoDB和Falcon，MyISAM并不支持事务。 

在默认情况下MySQL开启的是autocommit模式，也就是隐含的将每条语句当做一个事务处理，每条SQL都会被自动提交。当我们使用BEGIN或者START TRANSCATION时会把自动提交挂起，直到显示的调用COMMIT。使用事务可以有如下两种方法：

BEGIN;//开始事务，挂起自动提交

insert into t_c (user_id, s_id, amount, status) values(10001,10001,1,0);

insert into t_c (user_id, s_id, amount, status)values(10001,10002,1,0);

COMMIT;//提交事务，恢复自动提交

set autocommit = 0;//挂起自动提交

insert into t_c (user_id, s_id, amount, status)values(10001,10001,1,0);

insert into t_c(user_id, s_id, amount,  status)values(10001,10002,1,0);

COMMIT;//提交事务

set autocommit =1;//恢复自动提交

　　这两种方式效果相同。