事务的四大特性ACID
场景：小明向小强转账10元
原子性（Atomicity）
转账操作是一个不可分割的操作，要么转失败，要么转成功，不能存在中间的状态，也就是转了一半的这种情况。我们把这种要么全做，要么全不做的规则称之为原子性。
隔离性（Isolation）
另外一个场景：
- 小明向小强转账10元
- 小明向小红转账10元
隔离性表示上面两个操作是不能相互影响的
一致性（Consistency）
对于上面的转账场景，一致性表示每一次转账完成后，都需要保证整个系统的余额等于所有账户的收入减去所有账户的支出。
如果不遵循原子性，也就是如果小明向小强转账10元，但是只转了一半，小明账户少了10元，小强账户并没有增加，所以没有满足一致性了。
同样，如果不满足隔离性，也有可能导致破坏一致性。
所以说，数据库某些操作的原子性和隔离性都是保证一致性的一种手段，在操作执行完成后保证符合所有既定的约束则是一种结果。
实际上我们也可以对表建立约束来保证一致性。
持久性（Durability）
对于转账的交易记录，需要永久保存。
事务的概念
我们把需要保证原子性、隔离性、一致性和持久性的一个或多个数据库操作称之为一个事务
事务的使用
开启事务
方式一:
BEGIN WORK
BEGIN语句代表开启一个事务，后边的单词WORK可有可无。开启事务后，就可以继续写若干条语句，这些语句都属于刚刚开启的这个事务
方式二:
START TRANSACTION
START TRANSACTION语句和BEGIN语句有着相同的功效，都标志着开启一个事务
提交事务
COMMIT
手动中止事务(回滚)
ROLLBACK
这里需要强调一下，ROLLBACK语句是我们程序员手动的去回滚事务时才去使用的，如果事务在执行过程中遇到了某些错误而无法继续执行的话，事务自身会自动的回滚
查看事务是否自动提交
SHOW VARIABLES LIKE 'autocommit';
默认情况下，如果我们不显式的使用START TRANSACTION或者BEGIN语句开启一个事务，那么每一条语句都算是一个独立的事务，这种特性称之为事务的自动提交
如果我们想关闭这种自动提交的功能，可以使用下边两种方法之一：
- 显式的的使用START TRANSACTION或者BEGIN语句开启一个事务。这样在本次事务提交或者回滚前会暂时关闭掉自动提交的功能。
- 把系统变量autocommit的值设置为OFF，就像这样：这样的话，我们写入的多条语句就算是属于同一个事务了，直到我们显式的写出COMMIT语句来把这个事务提交掉，或者显式的写出ROLLBACK语句来把这个事务回滚掉。
SET autocommit = OFF;
隐式提交
当我们使用START TRANSACTION或者BEGIN语句开启了一个事务，或者把系统变量autocommit的值设置为OFF时，事务就不会进行自动提交，
但是如果我们输入了某些语句之后就会悄悄的提交掉，就像我们输入了COMMIT语句了一样，这种因为某些特殊的语句而导致事务提交的情况称为隐式提交，
这些会导致事务隐式提交的语句包括：
- 定义或修改数据库对象的数据定义语言（Data definition language，缩写为：DDL）。所谓的数据库对象，指的就是数据库、表、视图、存储过程等等这些东西。当我们使用CREATE、ALTER、DROP等语句去修改这些所谓的数据库对象时，就会隐式的提交前边语句所属于的事务。
- 隐式使用或修改mysql数据库中的表：当我们使用ALTER USER、CREATE USER、DROP USER、GRANT、RENAME USER、SET PASSWORD等语句时也会隐式的提交前边语句所属于的事务。
- 事务控制或关于锁定的语句：当我们在一个事务还没提交或者回滚时就又使用START TRANSACTION或者BEGIN语句开启了另一个事务时，会隐式的提交上一个事务。或者当前的autocommit系统变量的值为OFF，我们手动把它调为ON时，也会隐式的提交前边语句所属的事务。或者使用LOCK TABLES、UNLOCK TABLES等关于锁定的语句也会隐式的提交前边语句所属的事务。
- 加载数据的语句：比如我们使用LOAD DATA语句来批量往数据库中导入数据时，也会隐式的提交前边语句所属的事务。
- 其它的一些语句：使用ANALYZE TABLE、CACHE INDEX、CHECK TABLE、FLUSH、 LOAD INDEX INTO CACHE、OPTIMIZE TABLE、REPAIR TABLE、RESET等语句也会隐式的提交前边语句所属的事务。
保存点
如果你开启了一个事务，并且已经敲了很多语句，忽然发现上一条语句有点问题，你只好使用ROLLBACK语句来让数据库状态恢复到事务执行之前的样子，然后一切从头再来，总有一种一夜回到解放前的感觉。
MYSQL提出了一个保存点（英文：savepoint）的概念，就是在事务对应的数据库语句中打几个点，我们在调用ROLLBACK语句时可以指定会滚到哪个点，而不是回到最初的原点。
定义保存点的语法如下：
SAVEPOINT 保存点名称;
当我们想回滚到某个保存点时，可以使用下边这个语句（下边语句中的单词WORK和SAVEPOINT是可有可无的）
ROLLBACK [WORK] TO [SAVEPOINT] 保存点名称;
不过如果ROLLBACK语句后边不跟随保存点名称的话，会直接回滚到事务执行之前的状态。
如果我们想删除某个保存点，可以使用这个语句:
RELEASE SAVEPOINT 保存点名称;
事务隔离级别
事务的隔离级别有4个:由低到高依次为
大多数数据库的默认级别就是Read committed，比如Sql Server , Oracle。
Mysql的默认隔离级别就是Repeatable read。
查看隔离级别
select @@tx_isolation;
修改隔离级别
set session transaction isolation level read uncommitted;
读未提交（READ UNCOMMITTED）:
一个事务可以读到其他事务还没有提交的数据，会出现脏读。
一个事务读到了另一个未提交事务修改过的数据，这就是脏读。
实现简述：A会话 (repeatable read ）、B会话(read uncommitted) 。A会话中创建事务，然后修改数据，但不提交，B会话可以读到A未提交的数据： 以下按操作顺序依次执行。
A会话：
查看A的会话界别
使用数据库
开启事务
修改数据，但并未提交
B会话（A不关闭，重新启动一个会话）；
查看当前隔离界别
不修改隔离界别，发现数据并未读取到未提交的数据。
设置隔离界别为读未提交
读取到未提交的数据。
读已提交（READ COMMITTED）
一个事务只能读到另一个已经提交的事务修改过的数据，并且其他事务每对该数据进行一次修改并提交后，该事务都能查询得到最新值，会出现不可重复读、幻读
如果一个事务先根据某些条件查询出一些记录，之后另一个事务又向表中插入了符合这些条件的记录，原先的事务再次按照该条件查询时，能把另一个事务插入的记录也读出来，这就是幻读。
实现简述：在1的基础上，修改B会话的隔离界别为read commited ，发现脏读会被解决（及读取不到A会话未提交的数据）。
设置隔离界别为读已提交。脏读被解决。
问题：可重复读。
问题描述：A会话中，在B会话对数据进行第一次查询后，对该数据进行修改并提交 。B会话再对该数据进行查询，发现第二次和
第一次查询出来的数据不一致。
B会话：
设置隔离界别为读提交，开启事务，第一次查询数据。
A会话
查询数据、开启事务。修改数据。
提交数据。
查看数据已修改。
B会话
两次查询数据不一致。
可重复读（REPEATABLE READ）
一个事务第一次读过某条记录后，即使其他事务修改了该记录的值并且提交，该事务之后再读该条记录时，读到的仍是第一次读到的值，而不是每次都读到不同的数据，这就是可重复读，
这种隔离级别解决了不可重复，但是还是会出现幻读。
问题解决描述:在2的基础上，设置B会话的隔离界别为repeatable read，发现B会话再第一二次读取的数据一致。
B会话：
设置隔离界别为可重复读
A会话
修改数据
B会话
发现在同一个事物中两次读取数据一致
提交事务后，读取到修改后的数据。
问题描述：幻读，
A会话，查询数据时，发现主键id的数值到1，然后B开启事务，添加一个主键id为2的数据，之后提交数据。然后A会话，提交主键是2的数据，发现报（主键id为2的数据已存在）。但A缺没读取到，出现了幻读。
A会话
B会话
创建数据
A会话
第二次查询数据（不可重复读）后，添加报错，已存在 A会话出现幻读。
串行化（SERIALIZABLE）
以上3种隔离级别都允许对同一条记录同时进行读-读、读-写、写-读的并发操作，如果我们不允许读-写、写-读的并发操作，可以使用SERIALIZABLE隔离级别，这种隔离基金因为对同一条记录的操作都是串行的，所以不会出现脏读、幻读等现象。
问题描述：设置A会话为串行化（serializable），然后创建事务，查询users表后，在B会话中创建事务，往users表中添加数据发现被塞住了，只要A会话中的事务提交了，B会话才可添加成功（同样，A创建事务后（不查询users表），B创建事务后，添加数据到users表中（可成功，不提交事务，然后A会话查询users表，发现被塞住了，只有B会话的事务提交后，才可提交成功！）。避免了幻读，但很影响性能、
A会话
设置事务为串行化
创建事务查询users表
B会话
创建事务，可查询users表，但添加数据时被塞住
A会话提交数据
B会话中的添加操作执行（由于本机操作时间慢了，所以超时，速度快点会执行，然后B会话提交事务即可）。
总结
- READ UNCOMMITTED隔离级别下，可能发生脏读、不可重复读、幻读问题。
- READ COMMITTED隔离级别下，可能发生不可重复读和幻读问题，但是不会发生脏读问题。
- REPEATABLE READ隔离级别下，可能发生幻读问题，不会发生脏读和不可重复读的问题。
- SERIALIZABLE隔离级别下，各种问题都不可以发生。
- 注意：这四种隔离级别是SQL的标准定义，不同的数据库会有不同的实现，特别需要注意的是MySQL在REPEATABLE READ隔离级别下，是可以禁止幻读问题的发生的。
版本链
对于使用InnoDB存储引擎的表来说，它的聚簇索引记录中都包含两个必要的隐藏列（row_id并不是必要的，我们创建的表中有主键或者非NULL唯一键时都不会包含row_id列）：
- trx_id：每次对某条记录进行改动时，都会把对应的事务id赋值给trx_id隐藏列。
- roll_pointer：每次对某条记录进行改动时，这个隐藏列会存一个指针，可以通过这个指针找到该记录修改前的信息。
ReadView
对于使用READ UNCOMMITTED隔离级别的事务来说，直接读取记录的最新版本就好了，对于使用SERIALIZABLE隔离级别的事务来说，使用加锁的方式来访问记录。
对于使用READ COMMITTED和REPEATABLE READ隔离级别的事务来说，就需要用到我们上边所说的版本链了，核心问题就是：需要判断一下版本链中的哪个版本是当前事务可见的。
ReadView中主要包含4个比较重要的内容：
- m_ids：表示在生成ReadView时当前系统中活跃的读写事务的事务id列表。
- min_trx_id：表示在生成ReadView时当前系统中活跃的读写事务中最小的事务id，也就是m_ids中的最小值。
- max_trx_id：表示生成ReadView时系统中应该分配给下一个事务的id值。
- creator_trx_id：表示生成该ReadView的事务的事务id。
注意max_trx_id并不是m_ids中的最大值，事务id是递增分配的。比方说现在有id为1，2，3这三个事务，之后id为3的事务提交了。那么一个新的读事务在生成ReadView时，m_ids就包括1和2，min_trx_id的值就是1，max_trx_id的值就是4。
有了这个ReadView，这样在访问某条记录时，只需要按照下边的步骤判断记录的某个版本是否可见：
- 如果被访问版本的trx_id属性值与ReadView中的creator_trx_id值相同，意味着当前事务在访问它自己修改过的记录，所以该版本可以被当前事务访问。
- 如果被访问版本的trx_id属性值小于ReadView中的min_trx_id值，表明生成该版本的事务在当前事务生成ReadView前已经提交，所以该版本可以被当前事务访问。
- 如果被访问版本的trx_id属性值大于ReadView中的max_trx_id值，表明生成该版本的事务在当前事务生成ReadView后才开启，所以该版本不可以被当前事务访问。
- 如果被访问版本的trx_id属性值在ReadView的min_trx_id和max_trx_id之间，那就需要判断一下trx_id属性值是不是在m_ids列表中，如果在，说明创建ReadView时生成该版本的事务还是活跃的，该版本不可以被访问；如果不在，说明创建ReadView时生成该版本的事务已经被提交，该版本可以被访问。
READ COMMITTED的实现方式
每次读取数据前都生成一个ReadView
REPEATABLE READ实现方式
在第一次读取数据时生成一个ReadView
MVCC总结
MVCC（Multi-Version Concurrency Control ，多版本并发控制）指的就是在使用READ COMMITTD、REPEATABLE READ这两种隔离级别的事务在执行普通的SEELCT操作时访问记录的版本链的过程。可以使不同事务的读-写、写-读操作并发执行，从而提升系统性能。READ COMMITTD、REPEATABLE READ这两个隔离级别的一个很大不同就是：生成ReadView的时机不同，READ COMMITTD在每一次进行普通SELECT操作前都会生成一个ReadView，而REPEATABLE READ只在第一次进行普通SELECT操作前生成一个ReadView，之后的查询操作都重复使用这个ReadView就好了。