概念
事务就是保证一组数据库操作，要么全部成功，要么全部失败。
在MySQL中，事务是在引擎层实现的。
特性（ACID）
-
原子性（Atomicity）：
一个事务中的操作，要么全部成功，要么全部失败。 -
一致性（Consistency）：
事务开始前和结束后，数据库的完整性没有被破坏。 -
隔离性（Isolation）：
数据库支持多个事务同时对其数据进行读写和修改的能力，隔离性可以防止多个事务并发执行导致的数据不一致。 -
持久性（Durability）
事务结束后，对数据的修改就是永久的，即使系统故障也不会丢失。
隔离性与隔离级别
当数据库上有多个事务同时执行时，就可能出现脏读、不可重复读、幻读的问题，为了解决这些问题，就有了隔离级别的概念。
SQL标准的事务隔离级别包括：
-
读未提交（read uncommitted）
一个事务还没提交时，它做的变更就能被别的事务看到。 -
读提交（read committed）
一个事务只有提交后，它做的变更才能被别的事务看到。 -
可重复读（repeatable read）
一个事务执行过程中看到的数据，总是跟它在启动时看到的数据一致。 -
串行化（serializable）
当出现读写锁冲突的时候，后访问的事务必须等前一个事务完成，才能继续执行。
举例说明各个隔离级别
假设数据表T中只有一列，其中一行的值为1，下面是按照时间顺序执行两个事务的行为：
create table T(c int) engine=InnoDB;
insert into T(c) values(1);
来看看在不同的事务隔离级别下，事务A的V1，V2，V3的值分别是什么。
- 读未提交：虽然B还没提交，但是结果已经被A看到了，所以V1、V2、V3都是2
- 读提交：B的修改提交后，A才能看到，所以V1是1，V2、V3是2
- 可重复读：A在提交前，看到的数据都和A启动时看到的一致，所以V1、V2是1，V3是2
- 串行化：A先加了读锁，B在修改的时候，发生了读写锁冲突，所以等到A提交后，B的修改才会接着执行，所以V1、V2是1，V3是2
在实现上，数据库里面会创建一个视图，访问的时候以视图的逻辑结果为准。
在可重复读隔离级别下，这个视图是在事务启动时创建的，整个事务存在期间都用这个视图；
在读提交隔离级别下，这个视图是在SQL语句开始执行时创建的；
在读未提交隔离级别下，直接返回记录上的最新值，没有视图概念；
在串行化隔离级别下，直接用加锁的方式避免并行访问。
事务隔离的实现
在MySQL中，每条记录在更新的时候，都会同时记录一条回滚操作，记录上的最新值，通过回滚操作，都可以得到前一个状态的值。
假设一个值从 1 被按顺序改成了 2、3、4，在回滚日志里面就会有类似下面的记录。
当前值是 4，但是在查询这条记录的时候，不同时刻启动的事务会有不同的 read-view。在视图 A、B、C 里，这个记录的值分别为 1、2、4，同一条记录在系统中可以存在多个版本，这就是数据库的多版本并发控制（MVCC）。对于read-view A，想要得到 1，就得将当前值依次执行图中所有回滚操作才能得到。
回滚日志不会一直保留，系统会判断，当没有事务需要用到这些回滚日志的时候，回滚日志就会被删除。即当系统里没有比这个回滚日志更早的 read-view 的时候就会被删除。
为什么尽量不要使用长事务
长事务意味着系统里会存在很老的事务视图。由于这些事务随时会访问数据库里的任何数据，所以这个事务提交之前，数据库里它可能用到的回滚记录都必须保留，就会导致占用大量存储空间。
在 MySQL5.5 及以前的版本，回滚日志是跟数据字典一起放在 ibdata 文件里的，即使长事务最终提交，回滚段被清理，文件也不会变小。可能存在数据只有20G，而回滚段有 200G 的库，最终只好为了清理回滚段，而重建整个库。
除了对回滚段的影响，长事务还占用锁资源，也可能拖垮整个库。
长事务的查询方式：
可以在 information_schema 库的 innodb_trix 表中查询长事务。比如下面这个查找持续时间超过 60s 的事务：
select
*
from
information_schema.innodb_trx
where
TIME_TO_SEC(timediff(now(),trx_started)) > 60
