一基础概念
事务（Transaction）是访问和更新数据库的程序执行单元；
事务中可能包含一个或多个sql语句，这些语句要么都执行，
要么都不执行。作为一个关系型数据库，MySQL支持事务，本文介绍基于MySQL5.6。
mysql事务的基础知识
逻辑架构和存储引擎
如上图所示，MySQL服务器逻辑架构从上往下可以分为三层：
（1）第一层：处理客户端连接、授权认证等。
（2）第二层：服务器层，负责查询语句的解析、优化、缓存以及内置函数的实现、存储过程等。
（3）第三层：存储引擎，负责MySQL中数据的存储和提取。MySQL中服务器层不管理事务，事务是由存储引擎实现的。MySQL支持事务的存储引擎有InnoDB、NDB Cluster等，其中InnoDB的使用最为广泛；其他存储引擎不支持事务，如MyIsam、Memory等。
如无特殊说明，后文中描述的内容都是基于InnoDB。
2、提交和回滚
典型的MySQL事务是如下操作的：
tart transaction;
…… #一条或多条sql语句
commit;
其中start transaction标识事务开始，commit提交事务，将执行结果写入
到数据库。如果sql语句执行出现问题，会调用rollback，
回滚所有已经执行成功的sql语句。当然，也可以在事务中直接
使用rollback语句进行回滚。
自动提交
MySQL中默认采用的是自动提交（autocommit）模式
mysql> show variables like 'autocommit';
+---------------+-------+
| Variable_name | Value |
+---------------+-------+
| autocommit | ON |
+---------------+-------+
1 row in set (0.01 sec)
在自动提交模式下，如果没有start transaction显式地开始一个事务，那么每个sql语句都会被当做一个事务执行提交操作。
通过如下方式，可以关闭autocommit；需要注意的是，autocommit参数是针对连接的，在一个连接中修改了参数，不会对其他连接产生影响。
mysql> set autocommit = 0;
Query OK, 0 rows affected (0.00 sec)
mysql> show variables like 'autocommit';
+---------------+-------+
| Variable_name | Value |
+---------------+-------+
| autocommit | OFF |
+---------------+-------+
1 row in set (0.00 sec)
如果关闭了autocommit，则所有的sql语句都在一个事务中，
直到执行了commit或rollback，该事务结束，同时开始了另外一个事务。
特殊操作
在MySQL中，存在一些特殊的命令，如果在事务中执行了这些命令，
会马上强制执行commit提交事务；
如DDL语句(create table/drop table/alter/table)、
lock tables语句等等。常用的select、insert、update和delete命令，
都不会强制提交事务。
3、ACID特性
ACID是衡量事务的四个特性：
- 原子性（Atomicity，或称不可分割性）
- 一致性（Consistency）
- 隔离性（Isolation）
- 持久性（Durability）
按照严格的标准，只有同时满足ACID特性才是事务； 但是在各大数据库厂商的实现中，真正满足ACID的事务少之又少。 例如MySQL的NDB Cluster事务不满足持久性和隔离性； InnoDB默认事务隔离级别是可重复读，不满足隔离性； Oracle默认的事务隔离级别为READ COMMITTED， 不满足隔离性……因此与其说ACID是事务必须满足的条件， 不如说它们是衡量事务的四个维度。
二 、原子性
- 定义
原子性是指一个事务是一个不可分割的工作单位，其中的操作要么都做， 要么都不做；如果事务中一个sql语句执行失败， 则已执行的语句也必须回滚，数据库退回到事务前的状态。 - 实现原理：undo log
在说明原子性原理之前，首先介绍一下MySQL的事务日志。MySQL的日 志有很多种，如二进制日志、错误日志、查询日志、慢查询日志等，此外 InnoDB存储引擎还提供了两种事务日志：redo log(重做日志)和undo log(回滚日志)。其中redo log用于保证事务持久性；undo log则是事务原 子性和隔离性实现的基础。 下面说回undo log。实现原子性的关键，是当事务回滚时能够撤销所有已 经成功执行的sql语句。InnoDB实现回滚，靠的是undo log：当事务对数 据库进行修改时，InnoDB会生成对应的undo log；如果事务执行失败或 调用了rollback，导致事务需要回滚，便可以利用undo log中的信息将数 据回滚到修改之前的样子。 undo log属于逻辑日志，它记录的是sql执行相关的信息。当发生回滚 时，InnoDB会根据undo log的内容做与之前相反的工作：对于每个 insert，回滚时会执行delete；对于每个delete，回滚时会执行insert；对 于每个update，回滚时会执行一个相反的update，把数据改回去。 以update操作为例：当事务执行update时，其生成的undo log中会包含被 修改行的主键(以便知道修改了哪些行)、修改了哪些列、这些列在修改前 后的值等信息，回滚时便可以使用这些信息将数据还原到update之前的 状态。
三、持久性
- 定义
持久性是指事务一旦提交，它对数据库的改变就应该是永久性的。接下来 的其他操作或故障不应该对其有任何影响。 - 实现原理：redo log
redo log和undo log都属于InnoDB的事务日志。下面先聊一下redo log存 在的背景。 InnoDB作为MySQL的存储引擎，数据是存放在磁盘中的，但如果每次读写数据 都需要磁盘IO，效率会很低。为此，InnoDB提供了缓存(Buffer Pool)，Buffer Pool中包含了磁盘中部分数据页的映射，作为访问数据库的缓冲：当从数据库 读取数据时，会首先从Buffer Pool中读取，如果Buffer Pool中没有，则从磁盘读 取后放入Buffer Pool；当向数据库写入数据时，会首先写入Buffer Pool，Buffer Pool中修改的数据会定期刷新到磁盘中（这一过程称为刷脏）。 Buffer Pool的使用大大提高了读写数据的效率，但是也带了新的问题：如果 MySQL宕机，而此时Buffer Pool中修改的数据还没有刷新到磁盘，就会导致数 据的丢失，事务的持久性无法保证。 于是，redo log被引入来解决这个问题：当数据修改时，除了修改Buffer Pool中 的数据，还会在redo log记录这次操作；当事务提交时，会调用fsync接口对redo log进行刷盘。如果MySQL宕机，重启时可以读取redo log中的数据，对数据库 进行恢复。redo log采用的是WAL（Write-ahead logging，预写式日志），所有 修改先写入日志，再更新到Buffer Pool，保证了数据不会因MySQL宕机而丢 失，从而满足了持久性要求。 既然redo log也需要在事务提交时将日志写入磁盘，为什么它比直接将Buffer Pool中修改的数据写入磁盘(即刷脏)要快呢？主要有以下两方面的原因： （1）刷脏是随机IO，因为每次修改的数据位置随机，但写redo log是追加操 作，属于顺序IO。 （2）刷脏是以数据页（Page）为单位的，MySQL默认页大小是16KB，一个 Page上一个小修改都要整页写入；而redo log中只包含真正需要写入的部分，无 效IO大大减少。 - redo log与binlog
我们知道，在MySQL中还存在binlog(二进制日志)也可以记录写操作并用于数据 的恢复，但二者是有着根本的不同的：
（1）作用不同：redo log是用于crash recovery的，保证MySQL宕机也不会影响持久性；binlog是用于point-in-time recovery的，保证服务器可以基于时间点恢复数据，此外binlog还用于主从复制。
（2）层次不同：redo log是InnoDB存储引擎实现的，而binlog是MySQL的服务器层(可以参考文章前面对MySQL逻辑架构的介绍)实现的，同时支持InnoDB和其他存储引擎。
（3）内容不同：redo log是物理日志，内容基于磁盘的Page；binlog的内容是二进制的，根据binlog_format参数的不同，可能基于sql语句、基于数据本身或者二者的混合。
（4）写入时机不同：binlog在事务提交时写入；redo log的写入时机相对多元：
前面曾提到：当事务提交时会调用fsync对redo log进行刷盘；这是默认情况下的策略，修改
innodb_flush_log_at_trx_commit参数可以改变该策略，但事务的持久性将无法保证。
除了事务提交时，还有其他刷盘时机：如master thread每秒刷盘一次redo log等，
这样的好处是，不一定要等到commit时刷盘，commit速度大大加快。
四、隔离性
- 定义
与原子性、持久性侧重于研究事务本身不同，隔离性研究的是不同事务之间的 相互影响。隔离性是指，事务内部的操作与其他事务是隔离的，并发执行的各 个事务之间不能互相干扰。严格的隔离性，对应了事务隔离级别中Serializable (可串行化)，但实际应用中出于性能方面的考虑很少会使用可串行化。 隔离性追求的是并发情形下事务之间互不干扰。简单起见，我们仅考虑最简单 的读操作和写操作(暂时不考虑带锁读等特殊操作)，那么隔离性的探讨，主要可 以分为两个方面： 1. (一个事务)写操作对(另一个事务)写操作的影响：锁机制保证隔离性 2. (一个事务)写操作对(另一个事务)读操作的影响：MVCC保证隔离性 - 锁机制
首先来看两个事务的写操作之间的相互影响。隔离性要求同一时刻只能有一个 事务对数据进行写操作，InnoDB通过锁机制来保证这一点。 锁机制的基本原理可以概括为：事务在修改数据之前，需要先获得相应的锁； 获得锁之后，事务便可以修改数据；该事务操作期间，这部分数据是锁定的， 其他事务如果需要修改数据，需要等待当前事务提交或回滚后释放锁。
行锁与表锁
按照粒度，锁可以分为表锁、行锁以及其他位于二者之间的锁。表锁在操作数据时会锁定整张
表，并发性能较差；行锁则只锁定需要操作的数据，并发性能好。但是由于加锁本身需要消耗
资源(获得锁、检查锁、释放锁等都需要消耗资源)，因此在锁定数据较多情况下使用表锁可以
节省大量资源。MySQL中不同的存储引擎支持的锁是不一样的，例如MyIsam只支持表锁，而
InnoDB同时支持表锁和行锁，且出于性能考虑，绝大多数情况下使用的都是行锁。
如何查看锁信息
有多种方法可以查看InnoDB中锁的情况，例如：
select * from information_schema.innodb_locks; #锁的概况
show engine innodb status; #InnoDB整体状态，其中包括锁的情况
试验
事务1
mysql> start transaction; 操作1
Query OK, 0 rows affected (0.00 sec)
mysql> update user set name='cdb1' where id=19 ; 操作2
Query OK, 1 row affected (0.01 sec)
Rows matched: 1 Changed: 1 Warnings: 0
mysql> select * from information_schema.innodb_locks; 操作5
+---------------+-------------+-----------+-----------+----------------+------------+------------+-----------+----------+-----------+
| lock_id | lock_trx_id | lock_mode | lock_type | lock_table | lock_index | lock_space | lock_page | lock_rec | lock_data |
+---------------+-------------+-----------+-----------+----------------+------------+------------+-----------+----------+-----------+
| 34749:354:3:2 | 34749 | X | RECORD | `study`.`user` | PRIMARY | 354 | 3 | 2 | 19 |
| 34748:354:3:2 | 34748 | X | RECORD | `study`.`user` | PRIMARY | 354 | 3 | 2 | 19 |
+---------------+-------------+-----------+-----------+----------------+------------+------------+-----------+----------+-----------+
事务2 执行
mysql> start transaction; 操作3
Query OK, 0 rows affected (0.00 sec)
mysql> update user set name='cdb2' where id=19; 操作4
-- 等待锁释放
此时在事务1中执行操作5 查看锁情况
通过上述命令可以查看事务34749和34748占用锁的情况；其中lock_type为RECORD，代表锁为
行锁(记录锁)；lock_mode为X，代表排它锁(写锁)。
除了排它锁(写锁)之外，MySQL中还有共享锁(读锁)的概念。其他篇幅
- 脏读、不可重复读和幻读
-
事务隔离级别
3、4 见 mysql事务处理-四种隔离级别
- mvcc
RR（可重复读）解决脏读、不可重复读、幻读等问题，使用的是MVCC：MVCC全称 Multi-Version Concurrency Control，即多版本的并发控制协议。 下面的例子很好的体现了MVCC的特点： 在同一时刻，不同的事务读取到的数据可能是不同的(即多版本)——在T5时刻， 事务A和事务C可以读取到不同版本的数据。
mysql事务：ACID特性的实现原理 MVCC最大的优点是读不加锁，因此读写不冲突，并发性能好。InnoDB实现 MVCC，多个版本的数据可以共存，主要是依靠数据的隐藏列(也可以称之为标 记位)和undo log。其中数据的隐藏列包括了该行数据的版本号、删除时间、指 向undo log的指针等等；当读取数据时，MySQL可以通过隐藏列判断是否需要 回滚并找到回滚需要的undo log，从而实现MVCC，隐藏列的详细格式不再展开。
下面结合前文提到的几个问题分别说明。
-
总结
1）脏读
当事务A在T3时间节点读取zhangsan的余额时，会发现数据已被其他事务修改，且状态为未提
交。此时事务A读取最新数据后，根据数据的undo log执行回滚操作，得到事务B修改前的数
据，从而避免了脏读。
不可重复读
当事务A在T2节点第一次读取数据时，会记录该数据的版本号（数据的版本号是以row为单位记录
的），假设版本号为1；当事务B提交时，该行记录的版本号增加，假设版本号为2；当事务A在T5
再一次读取数据时，发现数据的版本号（2）大于第一次读取时记录的版本号（1），因此会根据
undo log执行回滚操作，得到版本号为1时的数据，从而实现了可重复读。
3）幻读
InnoDB实现的RR通过next-key lock机制避免了幻读现象。
next-key lock是行锁的一种，实现相当于record lock(记录锁) + gap lock(间隙锁)；其特点是不
仅会锁住记录本身(record lock的功能)，还会锁定一个范围(gap lock的功能)。当然，这里我们
讨论的是不加锁读：此时的next-key lock并不是真的加锁，只是为读取的数据增加了标记（标
记内容包括数据的版本号等）；准确起见姑且称之为类next-key lock机制。还是以前面的例子
来说明：
当事务A在T2节点第一次读取0<id<5数据时，标记的不只是id=1的数据，而是将范围(0,5)进行了
标记，这样当T5时刻再次读取0<id<5数据时，便可以发现id=4的数据比之前标记的版本号更高，
此时再结合undo log执行回滚操作，避免了幻读。
- 总结
概括来说，InnoDB实现的RR，通过锁机制、数据的隐藏列、undo log和类next- key lock，实现了一定程度的隔离性，可以满足大多数场景的需要。不过需要说 明的是，RR虽然避免了幻读问题，但是毕竟不是Serializable，不能保证完全的 隔离，下面是一个例子，大家可以自己验证一下。
五、一致性
- 基本概念
一致性是指事务执行结束后，数据库的完整性约束没有被破坏，事务执行的前后 都是合法的数据状态。数据库的完整性约束包括但不限于：实体完整性（如行的 主键存在且唯一）、列完整性（如字段的类型、大小、长度要符合要求）、外键 约束、用户自定义完整性（如转账前后，两个账户余额的和应该不变）。 - 实现
可以说，一致性是事务追求的最终目标：前面提到的原子性、持久性和隔离 性，都是为了保证数据库状态的一致性。此外，除了数据库层面的保障，一致 性的实现也需要应用层面进行保障。 实现一致性的措施包括： 1. 保证原子性、持久性和隔离性，如果这些特性无法保证，事务的一致性也 法保证 2. 数据库本身提供保障，例如不允许向整形列插入字符串值、字符串长度不能 超过列的限制等 3. 应用层面进行保障，例如如果转账操作只扣除转账者的余额，而没有增加接 收者的余额，无论数据库实现的多么完美，也无法保证状态的一致
六、总结
下面总结一下ACID特性及其实现原理：
- 原子性：语句要么全执行，要么全不执行，是事务最核心的特性，事务本身就是以原子性来定义的；实现主要基于undo log
- 持久性：保证事务提交后不会因为宕机等原因导致数据丢失；实现主要基于redo log
- 隔离性：保证事务执行尽可能不受其他事务影响；InnoDB默认的隔离级别是RR，RR的实现主要基于锁机制、数据的隐藏列、undo log和类next-key lock机制
- 一致性：事务追求的最终目标，一致性的实现既需要数据库层面的保障，也需要应用层面的保障
转自 并学习验证
https://www.cnblogs.com/kismetv/p/10331633.html