事务四大特征：原子性，一致性，隔离性和持久性。
事务四大特征：原子性，一致性，隔离性和持久性。
1、原子性（Atomicity）
一个原子事务要么完整执行，要么干脆不执行。这意味着，工作单元中的每项任务都必须正确执行。如果有任一任务执行失败，则整个工作单元或事务就会被终止。即此前对数据所作的任何修改都将被撤销。如果所有任务都被成功执行，事务就会被提交，即对数据所作的修改将会是永久性的。`
2. 一致性（Consistency）
一致性代表了底层数据存储的完整性。它必须由事务系统和应用开发人员共同来保证。事务系统通过保证事务的原子性，隔离性和持久性来满足这一要求; 应用开发人员则需要保证数据库有适当的约束(主键，引用完整性等)，并且工作单元中所实现的业务逻辑不会导致数据的不一致(即，数据预期所表达的现实业务情况不相一致)。例如，在一次转账过程中，从某一账户中扣除的金额必须与另一账户中存入的金额相等。
3. 隔离性（Isolation）
隔离性意味着事务必须在不干扰其他进程或事务的前提下独立执行。换言之，在事务或工作单元执行完毕之前，其所访问的数据不能受系统其他部分的影响。
5. 持久性（Durability)
持久性表示在某个事务的执行过程中，对数据所作的所有改动都必须在事务成功结束前保存至某种物理存储设备。这样可以保证，所作的修改在任何系统瘫痪时不至于丢失。
MySQL事务
1.基本概念
- 原子性。
整个事务是不可分割的最小单位，事务中任何一个语句执行失败，所有已经执行成功的语句也要回滚，整个数据库状态要恢复到执行事务前到状态。
- 一致性。
事务将数据库从一种状态转变为下一种一致的状态。在事务的前后，数据库的完整性约束没有被破坏。（事务的acid不是完全正交的，尤其是一致性，可能跟原子性、隔离性都有一定关系，后面会看到）
- 持久性。
事务一旦提交，那么就是永久性的，不会因为宕机等故障导致数据丢失（外力影响不保证，比如磁盘损害）。持久性是保证了数据库的高可靠性（High Reliability），而不是高可用性(Hign Availability)。高可用性并不能通过事务来保证。
2.持久性的实现
MySQL的innoDB存储引擎，使用Redo log保证了事务的持久性。
当事务提交时，必须先将事务的所有日志写入日志文件进行持久化，就是我们常说的WAL（write ahead log）机制（这个技术是保障持久性的关键技术，在HBase中也扮演重要角色，有兴趣的同学可以参考xxxxx）。这样才能保证断电或宕机等情况发生后，已提交的事务不会丢失，这个能力称为 crash-safe。
下面深入聊一聊redo log的机制，给大家更深刻的理解。
Redo log包括两部分，重做日志缓冲（redo log buffer）和重做日志文件（redo log file），前者是易失的缓存，后者是持久化的文件。
举一个事务的例子：
- 步骤1:begin;
- 步骤2:insert into t1 …r
- 步骤3:insert into t2 …
- 步骤4:commit;
这个事务的写入过程实际拆解如下：
innodb缓冲池的概念本文就不展开说明了，以后有机会可以展开说一下。
重点关注在这个事务提交前，将 redo log 的写入拆成了两个步骤，prepare 和 commit，这就是"两阶段提交”。
为什么要采用两阶段提交呢？
实际上，两阶段提交是分布式系统常用的机制。MySQL使用了两阶段提交后，也是为了保证事务的持久性。Redo log 和bingo 有一个共同的数据字段，叫 XID,崩溃恢复的时候，会按顺序扫描 redo log。
- 假设在写入binlog前系统崩溃，那么数据库恢复后顺序扫描 redo log，碰到只有 parepare、而没有 commit 的 redo log，就拿着 XID 去 binlog 找对应的事务，而且binlog也没写入，所以事务就直接回滚了。
- 假设在写入binlog之后，事务提交前数据库崩溃，那么数据库恢复后顺序扫描 redo log，碰到既有 prepare、又有 commit 的 redo log，就直接提交，保证数据不丢失。
这个事务要往两个表中插入记录，插入数据的过程中，生成的日志都得先写入redo log buffer ，等到commit的时候，才真正把日志写到 redo log 文件。（当然，这里不绝对，因为redo log buffer可能因为其他原因被迫刷新到redo log）。
而为了确保每次日志都能写入日志文件，在每次将重做日志缓冲 写入 重做日志文件 后，InnoDB存储引擎都需要调用一次fsync操作，确保写入了磁盘。
对于redo log的持久化，可以如下图所示。
1）先写入redo log buffer，在蓝色区域。
2）写入redo log file，但是还没有fsync，这时候是处于黄色的位置，处于系统缓存。
3）调用fsync，真正写入磁盘。
为了控制 redo log 的写入策略，InnoDB 提供了 innodb_flush_log_at_trx_commit 参数，它有三种可能取值：
- 设置为 0 的时候，表示每次事务提交时都只是把 redo log 留在 redo log buffer 中 ;
- 设置为 1 的时候，表示每次事务提交时都将 redo log 直接持久化到磁盘；
- 设置为 2 的时候，表示每次事务提交时都只是把 redo log 写到 page cache。
binlog的写入和redo log一样，也是包括bingo cache和bingo file，同样跟上面的三色层次类似（当然，binlog是server层的，不是存储引擎层的），包括log buffer、文件系统page cache、hard disk。
写入page cache 和 fsync到disk 的时机，是由参数 sync_binlog 控制的：
- sync_binlog=0 的时候，表示每次提交事务都只 写入文件系统的page cache，不 fsync；
- sync_binlog=1 的时候，表示每次提交事务都会执行 fsync；
- sync_binlog=N(N>1) 的时候，表示每次提交事务都写入文件系统的page cache，但累积 N 个事务后才 fsync。（如果主机发生异常重启，会丢失最近 N 个事务的 binlog 日志）
通常我们说 MySQL 的“双 1”配置，指的就是 sync_binlog 和 innodb_flush_log_at_trx_commit 都设置成 1。也就是说，一个事务完整提交前，需要等待两次刷盘，一次是 redo log（prepare 阶段），一次是 binlog。
特别需要区分的是，redo log和binlog的不同。这也是经常在面试中可能会问到的两种日志的差异。
注意有这么几点：
- 产生位置不同。
redo log是innodb的存储引擎产生的，而binlog是数据库的server层实现的。换句话说，如果你使用MySQL，换其他存储引擎，那么可能没有redo log，但是还是会有binlog。
- 日志记录的内容形式不同。
binlog是一种逻辑日志，记录对应的SQL语句，而redo log记录了物理日志，是针对每个数据页的修改。
- 日志写入磁盘时间不同。
binlog只有在事务提交后完成一次写入，对于一个事物而言，在binlog中只有一条记录。而redo log在事务进行中不断被写入，而且是并发写入的，不是顺序写入的。
- 保存方式不同。
redo log 是循环写的，空间固定会用完；binlog 是可以追加写入的。“追加写”是指 binlog 文件写到一定大小后会切换到下一个，并不会覆盖以前的日志。
3.原子性的实现
Undo log保证了事务的原子性。
在对数据库进行修改时，innoDB引擎除了会产生redo log，还会产生undo log。InnoDB实现回滚，靠的是undo log：当事务对数据库进行修改时，InnoDB会生成对应的undo log；如果事务执行失败导致事务需要回滚，就利用undo log中的信息将数据回滚到修改之前的样子。
有人认为undo log是redo log的逆过程，其实是不对的。两个日志文件其实都能看作是一种对数据的恢复操作，redo log恢复事务导致的数据页的修改，而undo log能够恢复数据记录到某个特定的版本。
所以redo log是一种物理日志（数据页的修改），而undo log是一种逻辑日志（数据记录）。
undo log还要另外一个重要作用，就是用于mvcc中，进行多版本控制，也就是实现事务隔离性的基础，当用户读取一行记录时，如果这个记录已接被其他事务占用，那么当前事务就可以通过undo读取之前的行版本信息，用来实现非锁定读取，就是“快照读”。（事务隔离性的问题，可以看我上一篇文章 跟面试官侃半小时MySQL事务隔离性，从基本概念深入到实现 ）。
4.一致性的实现
就像一开始在定义的时候介绍的，事务的ACID性质不是完全正交的，尤其是一致性，我们可以认为原子性、持久性和隔离性都是为了实现事务的一致性。
当然，这里的一致性是指数据库层面的事务一致性。
如果说你在应用层面做一个操作，给转账者扣钱，没给接收者加钱，那么这个不一致跟事务的不一致是没有关系的，需要开发人员自己做业务逻辑一致性的保证。
5 、隔离性的实现
1.事务隔离性的基本概念
1.1 什么是ACID中的Isolation,隔离性
Isolation,隔离性，也有人称之为并发控制（concurrency control）。事务的隔离性要求每个事务读写的对象对其他事务都是相互隔离的，也就是这个事务提交前，这个事务的修改内容对其他事务都是不可见的。事务的隔离性，主要是解决不同事物之间的相互读写影响。
所谓的读写影响注意分为三种：
-
脏读：读到了别的事务尚未提交（commit）的变更，别人没提交，我读到了。
-
不可重复读：别的事务提交了变更，被当前事务读到了。然后导致本事务多次select的结果不一样，读到了别的事务提交的内容。
-
幻读：也是读到了别的事务提交的内容，但是跟上面的不同之处在于，读到了原本不存在的记录。
注意，不可重复读，主要是读到了别的事务update的内容。而幻读，是读到了别的事务insert的内容。
1.2 隔离性的隔离级别
为了解决事务隔离性的问题，数据库一般会有不同的隔离级别来解决相应的读写影响。
-
读未提交：一个事务B还没提交，它的修改就被别的事务A读到了。
-
读已提交：一个事务B提交后，它的修改被其他事务A看到了。
-
可重复读：一个事物B提交前和提交后，事务A都无法读到事务B的变更。
-
串行化：对同一行记录，当出现不同事物的读写冲突时，是通过串行化的方式解决的，后一个事务必须等前一个事务完成才能执行。
不同隔离级别能够解决不同的隔离性问题。
需要注意的是，这是标准事务隔离级别的定义。在MySQL的innodb引擎中，在可重复读级别下，通过mvcc解决了幻读的问题，具体实现我们后面再讲。
同时，需要注意的是，到目前为止，我们说的读，都是”快照读”，普通的select。后面我们还会提到“当前读”，是不一样的哦。
2.事务隔离性的实现
要实现事务的隔离性，需要了解两个方面的内容，一个是锁，一个是多版本并发控制（MVCC）。
2.1 事务的行锁
InnoDB中，实现了两种标准的行级锁：
-
共享锁（S Lock），也叫读锁，允许事务读取一行数据。
-
排它锁（X Lock），也叫写锁，允许事务删除或者更新一行数据（注意，这里没有提到插入哦，插入涉及到幻读，可以看文章最后的说明）
普通select语句不会有任何锁，那么如何获得共享锁和排它锁呢？
-
Select … lock in share mode语句能够获得共享锁
-
Select … for update（特殊的select，用mysql简单实现分布式锁经常用它）、Update、delete语句能够获得排它锁
当一个事务A已经获得了行r的共享锁，那么另一个事务B可以立刻获得行r的共享锁，因为不会改变r的数值，这种叫做锁兼容。
如果这时候有事务C希望获得行r的排它锁，那么就必须等待事务A和事务B释放行r的共享锁之后，才能获得排它锁，这种叫做锁不兼容。
普通的select不会对行上锁，而select…lock in share mode会上共享锁，select…for update会上排它锁。
-
对于普通的select的读取方式，称为”快照读“，也叫”一致性非锁定读“。
-
对于带锁的select读取，或者update tb set a = a+1（读取a的当前值），称为“当前读”，也叫“一致性锁定读”。
如果在update、insert的时候，不能进行select，那么服务的并发访问性能就太差了。因此，我们日常的查询，都是“快照读”，不会上锁，只有在update\insert\“当前读”的时候，才会上锁。而为了解决“快照读”的并发访问问题，就引入了MVCC。
2.2 多版本并发控制MVCC
如果说上面的行锁是一种悲观锁，那么MVCC就是一种乐观锁的实现方式，而且是一种很常用的乐观锁实现方式。
所谓多版本，就是一行记录在数据库中存储了多个版本，每个版本以事务ID作为版本号。InnoDB 里面每个事务有一个唯一的事务 ID，是在事务开始的时候向InnoDB的事务系统申请的，并且按照申请顺序严格递增的。假如一行记录被多个事务更新，那么，就会产生多个版本的记录。
以某一行数据作为例子：
经过两次事务的操作，value从22变成了19，同时，保留了三个事务id，15、25、30。
在每个记录多版本的基础上，需要利用“一致性视图”，来做版本的可见性判断。
这里，我们要区分MySQL里面的两个”视图”概念：
-
一个是view，通过语法create view … 实现，主要创建一个虚拟表，用来执行查询语句。
-
一个是InnoDB用来实现mvcc的一致性视图（consistent read view），纯逻辑概念，没有物理结构，定义了在事务期间，你能看到哪些版本的数据。
我们全文提到的“视图”都是第二种，主要是支持InnoDB在“读已提交”和“可重复读”级别的并发访问问题。
-
“读未提及”级别下，没有一致性视图
-
“读已提交”级别下，会在 每个SQL开始执行的时候 创建一致性视图
-
“可重复读”级别下，会在 每个事务开始的时候 创建一致性视图
-
“串行化”级别下，直接通过加锁避免并发问题
下面，我们简单介绍一下创建一致性视图的逻辑。
以“可重复读”级别为例。
-
当一个事务开启的时候，会向系统申请一个新事务id
-
此时，可能还有多个正在进行的其他事务没有提交，因此在瞬时时刻，是有多个活跃的未提交事务id
-
将这些未提交的事务id组成一个数组，数组里面最小的事务id记录为低水位，当前系统创建过的事务id的最大值+1记录为高水位
-
这个数组array 和 高水位，就组成了“一致性视图”。
有了一致性视图后，我们就可以判断一行数据的多版本可见性了，无论是“读已提交”还是“可重复读”级别，可见性判断规则是一样的，区别在于创建快照（一致性视图）的时间。
在当前事务中，读取其他某一行的记录，对其中的版本号的可见性判断有五种情况（建议自己跟着捋一捋，挺重要的）：
-
如果版本号小于“低水位”，说明事务已经提交，那肯定 可见；
-
如果版本号大于“高水位”，说明这行数据的这个事务id版本是在快照后产生的，那肯定 不可见；
-
如果版本号在事务数组array中，说明这个事务还没提交，所以 不可见；
-
如果版本号不在事务数组array中，且低于高水位，说明这个事务已经提交，所以 可见；
-
当然，无论什么时候，自己的事务id中的任何变化，都是可见的
可以看看下面这个例子，更容易理解。
系统创建过的事务id：1,2,3,4,5,6,7,8,9,10,11,12,13,14,15
事务A启动，拍个快照
此时未提交的事务id有：7，8，9
一致性视图：数组array[7,8,9] + 高水位16（15+1）
对于任意一行数据的可见性判断：
-
小于7的，可见
-
大于16的，说明是快照后产生的，不可见
-
10-15，不在数组array中，说明已经提交了，可见
-
7，8，9在array中，说明未提交，不可见
两个重要结论：
-
InnoDB 利用了“所有数据都有多个版本”的这个特性，实现了“秒级创建快照”的能力。
-
MVCC的实现，就是根据当前事务的事务id为依据创建“一致性视图”，利用一致性视图来判断数据版本的可见性。
3.隔离性实战
下面，我们来两个实战案例，将上面的基础概念与实现融会贯通吧。
1）并发select&update 案例
id=1 的value初始为1。
我们看下，在不同隔离级别，Time5、Time7、Time9事务A查询到的value 分布为多少。
-
“读未提交”：2，2，2
-
“读以提交”：1，2，2
-
“可重复读”：1，1，2
-
串行化：1，1，2（注意，这里在事务A提交前，事务B都会阻塞，直到事务A提交后才能执行）
2）并发update案例
id=1 的value初始为1，在可重复读级别：
我们看一下，你猜猜事务A和事务B读取的value是多少？
答案是：1 和 3
可能会产生困惑，事务A在启动后快照，所以读到了1是正常的，但是事务2在启动的时候快照了，然后在自己的事务中+1，怎么会读到3而不是2呢？
原因很简单，即使是在可重复读的级别，事务 更新数据 的时候，只能用当前读（想想也能理解，不然update就出现数据不一致了）。
如果当前的记录的行锁被其他事务占用的话，就需要进入锁等待。而读提交的逻辑和可重复读的逻辑类似，它们最主要的区别是：在可重复读隔离级别下，只需要在事务开始的时候创建一致性视图，之后事务里的其他查询都共用这个一致性视图；在读提交隔离级别下，每一个语句执行前都会重新算出一个新的视图。
这里，我们需要注意的是事务的启动时机。
-
begin/start transaction 命令并不是一个事务的起点，在执行到它们之后的第一个操作 InnoDB 表的语句，事务才真正启动,一致性视图是在执行第一个快照读语句时创建的。
-
如果你想要马上启动一个事务，可以使用 start transaction with consistent snapshot 这个命令，一致性视图是在执行 start transaction with consistent snapshot 时创建的。
4.关于幻读
前文已经提到了，对于普通数据库，需要到可串行化的隔离级别才能解决幻读问题。
而对于InnoDB存储引擎来说，在可重复读级别下就能解决幻读问题。
InnoDB存储引擎有三种行锁算法：
-
行锁：当个行记录上的锁
-
间隙锁：Gap Lock，锁定一个范围，但不包含记录本身
-
Next-Key Lock:就是行锁+间隙锁，同时锁上一个范围，并且锁定记录本身
InnoDB就是通过Next-Key Lock解决了幻读的问题，具体内容可以看我之前的文章： 两文说透MySQL里的各种锁（下篇）