隔离性与隔离级别 Isolation

解决的问题

当数据库上有多个事务同时执行的时候，就可能出现脏读（dirty read）、不可重复读（non-repeatable read）、幻读（phantom read）的问题，为了解决这些问题，就有了“隔离级别”的概念。

SQL 标准的事务隔离级别包括：

读未提交（read uncommitted）
- 读未提交是指，一个事务还没提交时，它做的变更就能被别的事务看到。
读提交（read committed）
- 读提交是指，一个事务提交之后，它做的变更才会被其他事务看到。
可重复读（repeatable read）
- 一个事务执行过程中看到的数据，总是跟这个事务在启动时看到的数据是一致的。
- 当然在可重复读隔离级别下，未提交变更对其他事务也是不可见的。
串行化（serializable ）
- 对于同一行记录，“写”会加“写锁”，“读”会加“读锁”。
- 当出现读写锁冲突的时候，后访问的事务必须等前一个事务执行完成，才能继续执行

假设一个值从 1 被按顺序改成了 2、3、4，在回滚日志里面就会有类似下面的记录。

当前值是 4，但是在查询这条记录的时候，不同时刻启动的事务会有不同的 read-view。

如图中看到的，在视图 A、B、C 里面，这一个记录的值分别是 1、2、4，同一条记录在系统中可以存在多个版本，就是数据库的多版本并发控制（MVCC）

1.长事务意味着系统里面会存在很老的事务视图。

由于这些事务随时可能访问数据库里面的任何数据，所以这个事务提交之前，数据库里面它可能用到的回滚记录都必须保留，这就会导致大量占用存储空间。

2.除了对回滚段的影响，长事务还占用锁资源，也可能拖垮整个库，这个我们会在后面讲锁的时候展开。

begin 或 start transaction。配套的提交语句是 commit，回滚语句是 rollback。

这个命令会将这个线程的自动提交关掉。

意味着如果你只执行一个 select 语句，这个事务就启动了，而且并不会自动提交。

这个事务持续存在直到你主动执行 commit 或 rollback 语句，或者断开连接。

有些客户端连接框架会默认连接成功后先执行一个 set autocommit=0 的命令。这就导致接下来的查询都在事务中，如果是长连接，就导致了意外的长事务。

在 information_schema 库的 innodb_trx 这个表中查询长事务，比如下面这个语句，用于查找持续时间超过 60s 的事务。

select * from information_schema.innodb_trx where TIME_TO_SEC(timediff(now(),trx_started))>60