什么是事务
数据库事务是mysql实行实际操作的最少逻辑性企业，一个事务管理能够包括一个或是好几个sql语句，这种sql要不都实行取得成功要不都实行不成功。高并发实际操作下，事务管理的操纵至关重要。
事务管理的特性（ACID）
原子性、一致性、防护性、持续性
原子性（Atomicity）：意思是事务管理中的全部实际操作做为一个总体，要不所有取得成功，要不所有不成功
原子性的最底层基本原理（怎样完成）：undo log日志（回退日志）；
分子特性完成的关键是在不成功的情况下可以产生回退。而回退就取决于 undo log 日志。事务管理在变更数据信息以前会即将变更的备份数据到undo log中（undo log会储存变更前的数据信息，是一个行等级的历史记录），假如发生了不正确或是客户实行了rollback，就可以根据undo log将数据修复到事务管理逐渐以前的情况。
Undo log如何保证回退的呢？你能了解为：
如果你在事务管理中delete一条纪录时，undo log 会纪录一条相匹配的insert 纪录。
如果你在事务管理中insert一条纪录的情况下，undo log 会纪录一条相匹配的delete纪录
如果你在事务管理中update一条纪录时，它纪录一条反过来的update纪录。
当rollback回退的情况下，便会实行这种反过来的实际操作。
当然，undo log里边并不会确实纪录这种一条条的sql指令，只是留着行数据信息的內容。
Undo log是逻辑性日志，以后说的redo log是物理学日志。逻辑性日志的储存文件格式是以段的文件格式储存数据信息，物理学日志的储存文件格式是以页的文件格式储存（mysql的一个页有16K，一个页能够有好几个行）。
Undo日志储存在了data文件目录下的ibdata文档中：
Undo log除开可以完成原子性以外，还能用以完成多版本号高并发操纵（MVCC）
PS：undo, redo 这两个日志仅有应用innodb这一储存模块的情况下才会采用。Binlog日志归属于服务项目层的一个物品，全部种类的储存模块都能够应用。
防护性（isolation）：意思是高并发实行的事务管理不容易互相影响，高并发实行的实际操作的結果和她们串行通信实行时的結果一样。
防护性的最底层基本原理（怎样完成）：是根据锁来完成的。锁会再后边的章节目录中详细描述，这儿先不提，只必须直至防护性是根据锁来完成的就可以。
持续性（Durability）:事务管理一旦递交，对数据库查询的升级是长久的。一切的事务管理或是常见故障都不容易造成内容丢失。
持续性的最底层基本原理：根据redo log 日志（前滚日志），redo日志纪录着事务管理中，变更后的数据信息。储存的文件格式为页。
假如事务管理commit以后，mysql已经将数据信息载入数据分析表的情况下，mysql或是全部网络服务器产生服务器宕机，这时myslq的表中還是一个旧的数据信息。可是下一次重新启动的情况下，mysql会依据载入 redo log文档的內容，将数据修复成全新的情况。可是假如redo log也没都还没持久化，那这些的数据信息就确实遗失了。但是redo log的日志数据信息从缓存文件载入redo日志文档会比数据信息载入数据分析表要快。由于redo日志文档的內容非常少，它只储存事务管理中改动的数据信息，因此 io载入redo日志会迅速，而数据分析表文档內容非常大，io载入表文档会较慢。
当然，要是没有产生一切常见故障，mysql不服务器宕机哪些的，数据信息取得成功载入到数据分析表文档，那麼redo日志中储存这的这种数据信息之后也就用不到了，这个时候mysql会有一套体制将redo日志文档的內容删掉。因此 redo文档储存的日志是临时性的，仅用以常见故障时避免 数据分析表内容丢失，不容易一直存有，不然redo文档会越来越大，并且没有意义。
一句话：数据分析表的数据信息没都还没持久化问题不大，只需redo log文档纪录的数据信息在服务器宕机前持久化了就OK。
一致性（Consistency）：事务管理的实行結果务必是数据库查询从一个一致性情况到另一个一致性情况。例如转帐前后左右2个帐户的额度总数应当不会改变。
所述四个特性中，一致性是事务管理的最后目地。只需别的三个特点都考虑了，那麼一致性顺理成章也便会考虑，换句话说原子性，防护性和持续性是因，一致性是果。
==========================================================
Redo 和 Undo 日志（前滚日志和回退日志）
下边大家看一下一个事务管理里边，undo log 和 redo log 到底是如何纪录的。最先要了解一个定义：大家说的undo日志和redo日志不仅是她们在硬盘中的日志文档，还包含她们在缓冲区域buffer中的日志，要了解纪录undo日志和redo日志的情况下不太可能立即载入到硬盘，只是要先载入到运行内存，再从运行内存fsync到硬盘。
假定有一个innodb表，我对在其中的二行数据信息A,B（只有一个字段名f,f的值分别是1,2）开展改动。
start transation
Update A set f=10 where id=1; # 这时会先把id为1的纪录从硬盘（数据分析表文档）读到mysql过程的运行内存开展改动f字段名。在改动前先将 f=1 这一旧数据信息载入到客户室内空间的undo日志缓冲区域(undo log buffer); 改动之后将 f=10 这一新数据载入到客户室内空间的redo 日志缓冲区域(redo log buffer); 另外也会将f=10载入到数据信息缓冲区域（data buffer）中
Update B set f=20 where id=1; # 跟上面一样实际操作。
Commit; # 这时，旧数据信息和新数据会从客户室内空间的缓冲区域（便是mysql这一过程的运行内存）拷到核心室内空间的缓冲区域（OS buffer）。并实行系统进程 fsync()，将 f=1 这一老数据信息从核心态的运行内存载入到 undo log 硬盘文档（地刷），将 f=10 这一新数据也从核心态的运行内存载入到redo log硬盘文档中。最终将 f=10 从数据信息缓冲区域载入到数据分析表的硬盘中。
Commit的情况下产生的事儿，我效仿了在网上的一张图：
当实行commit的情况下，mysql过程会将以前写在客户态运行内存（log buffer日志缓冲区域）的新老数据信息拷到核心态的核心缓冲区域(os buffer)，随后实行fsync()这一系统进程，把数据信息地刷（从核心态的运行内存载入到redo和undo硬盘文档中）。留意，fsync是一个多线程的io实际操作，不用cpu的参加。
倘若，commit以前，由于一些不正确产生回退，这时会用客户态的undo buffer中的旧数据信息实行一些反实际操作（例如实行的是insert实际操作，回退的情况下便是一个delete实际操作），把数据信息缓冲区域中的內容修复为旧数据信息。
这就是undo日意在回退是的功效，回退的全过程中是用的undo 缓冲区域中的日志，而不是undo硬盘文档中的日志，由于这个时候undo日志都还没载入到硬盘中。
Undo日志是事务管理中旧数据信息(f=1)的备份数据，redo日志是事务管理中澳数据信息(f=10)的备份数据。
下边也有幅图能够帮你了解事务管理实行时，redo和undo日志及其数据信息的地刷全过程
注重一下：在事务管理中实行一条非查看的sql，redo/undo日志会载入到客户态缓冲区域但还没有载入到核心缓冲区域；仅有commit的情况下才会载入到核心缓冲区域和地刷。（硬盘或是运行内存中的）redo和undo日志纪录的并不是实际的sql指令，只是数据信息自身。
============================================
Commit的情况下，将 日志buffer 载入到 日志文档这一全过程有3中方法，我们可以根据改动自变量 innodb_flush_log_at_trx_commit 的值来决策，该自变量有3种值：0、1、2，默认设置为1。
0：mysql会设定一个计划任务，每过（大概）一秒将客户态的log bufer中现有的数据信息（包含undo和redo的日志数据信息）拷到核心 os buffer，并立刻启用fsync()刷出硬盘。在这一秒以内，很有可能也有别的的手机客户端实行了事务管理把redo和undo日志写到log buffer，这时就可以将她们的日志一起刷出硬盘中。
1：当实行commit时，mysql会立刻把日志数据信息从log buffer载入os buffer而且立刻地刷。
2：当实行commit时，mysql会立刻把日志数据信息从log buffer载入os buffer但不容易立刻地刷。另外mysql会设定一个计划任务，每过一秒启用fsync()把数据信息从核心刷出硬盘。
假如一秒还没有到，可是buffer中的数据信息早已占了buffer被分配内存的一半之上时，系统软件依然会把数据信息从buffer刷出硬盘
从高效率上而言，0和2是较为高的，因为它地刷的頻率没那麼高，io频次较为少。可是当mysql宕掉或是这一设备宕掉的情况下会遗失1s的数据信息。1的安全等级最大，可是高效率较为低，会提升硬盘工作压力。
等级0和等级2对比的差别取决于，在数据信息从运行内存同歩到硬盘的全过程中，假如mysql过程宕掉，等级0很有可能会遗失一秒的数据信息（由于数据信息在mysql过程客户态的运行内存中），可是等级2不容易遗失数据信息（由于数据信息这时再核心的运行内存中，早已和mysql过程挂钩了）。如果是全部设备宕没了等级2才会丢数据信息。
下面大家说说redo log的地刷实际全过程：
Redo log 文档的储放部位在data文件目录中，默认设置有两个redo log日志文档。
并且每一个redo log文件的较大 容积是固定不动的，数据信息超出了这一容积便会清除这一日志文档。是否很好奇怎么会有两个？
在innodb将log buffer中的redo log block刷出这种log file里时，会以增加载入的方法轮询载入。即先在第一个log file（即ib_logfile0）的尾端增加写，直至满了以后向第二个log file（即ib_logfile1）写。当第二个log file满了会清除一部分第一个log file再次载入。
这儿有一个留意点：
大家大部分人都觉得像下边那样把好几个sql句子装包实行和递交才算是一个事务管理。
Start transaction;
update xxx
select xxx
delete xxx
Commit
实际上不对，大家平常实行一个独立的sql句子实际上也是一个事务管理。比如：
Insert into t values (xxxxx);
这就是一个事务管理，只不过是mysql帮大家全自动commit了。
因此 实际上实行那样的单句sql，也是一个事务管理也会纪录到undo和redo中
PS：rollback和commit都是会完毕事务管理，都是会释放出来事务管理中造成的锁。如实行了rollback和commit后想再应用事务管理，请再次实行begin。
