MySQL实战45讲学习笔记：第三讲

一、事务的特性

原子性Atomicity、一致性Consistency、隔离性Isolation、持久性Durability

当事务同时执行的时可能出现的问题:

可重复度(non repeatable read)

脏读(dirty read)

幻读(phantom read)

解决方式:(四种隔离级别)

读未提交（read uncommitted）

读提交（read committed）

可重复读（repeatable read）

串行化（serializable ）

理论化的解释:

读未提交是指，一个事务还没提交时，它做的变更就能被别的事务看到。

读提交是指，一个事务提交之后，它做的变更才会被其他事务看到。

可重复读是指，一个事务执行过程中看到的数据，总是跟这个事务在启动时看到的数据是一致的。当然在可重复读隔离级别下，未提交变更对其他事务也是不可见的。

串行化，顾名思义是对于同一行记录，“写”会加“写锁”，“读”会加“读锁”。当出现读写锁冲突的时候，后访问的事务必须等前一个事务执行完成，才能继续执行。

幽默化的解释:

读未提交：别人改数据的事务尚未提交，我在我的事务中也能读到。
读已提交：别人改数据的事务已经提交，我在我的事务中才能读到。
可重复读：别人改数据的事务已经提交，我在我的事务中也不去读。
串行化：我的事务尚未提交，别人就别想改数据。
这4种隔离级别，并行性能依次降低，安全性依次提高。

查看当前mysql的隔离级别

mysql> show variables like 'transaction_isolation';

实际测试代码如下：

mysql> create table T(c int) engine=InnoDB;
Query OK, 0 rows affected (0.01 sec)
 
mysql> insert into T(c) values(1);
Query OK, 1 row affected (0.01 sec)

 

 我们来看看在不同隔离级别下，事务A会有哪些不同的返回结果，也就是图里面V1、V2、V3的返回值分别是什么？

 

可重复读的场景: 

假设你在管理一个个银行账户表，

1、一个表存了每个月月底的余额，一个表存了账单明细，

2、这时候你要做数据校对，也就是判断上个月的余额和当前余额的差额，是否与本月的账单明细一直

3、你一定希望在校对的过程中，即使有用户发生了一笔新的交易，也不影响你的校对结果

这时候"可重复读"隔离级别就很方便，事务启动时的视图可以认为是静态的，不受其他事务更新的影响

 

二、事务隔离的实现

1.事务隔离的实现

在 MySQL 中，实际上每条记录在更新的时候都会同时记录一条回滚操作。记录上的最新值，通过回滚操作，都可以得到前一个状态的值。

数据库的多版本并发控制（MVCC）:每条记录在更新的时候都会同时记录一条回滚操作。同一条记录在系统中可以存在多个版本

2.事务隔离的相关问题

1>回滚日志什么时候删除？

系统会判断当没有事务需要用到这些回滚日志的时候，回滚日志会被删除

2>什么时候不需要了？

当系统里没有比这个回滚日志更早的read-view的时候。

3>为什么尽量不要使用长事务

长事务意味着系统里面会存在很老的事务视图，在这个事务提交之前，回滚记录都要保留，这会导致大量占用存储空间。除此之外，长事务还占用锁资源，可能会拖垮库。

三、事务启动方式

1.启动方式

方式1:显式启动事务语句，begin或者start transaction,提交commit，回滚rollback；

方式2:set autocommit=0，该命令会把这个线程的自动提交关掉。这样只要执行一个select语句，事务就启动，

并不会自动提交，直到主动执行commit或rollback或断开连接

建议使用方式1：

如果考虑多一次交互问题，可以使用commit work and chain语法。在autocommit=1的情况下用begin显式启动事务，

如果执行commit则提交事务。如果执行commit work and chain则提交事务并自动启动下一个事务。

2.如何查询长事务

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

四、经典发言:

1、Gavin同学的形象实例

下面是我的自问自答，也是我的学习笔记，问下斌哥，这样理解准确吗？
在可重复读的隔离级别下，如何理解**当系统里没有比这个回滚日志更早的 read-view 的时候**，这个回滚日志就会被删除？

这也是**尽量不要使用长事务**的主要原因。

比如，在某个时刻（今天上午9:00）开启了一个事务A（对于可重复读隔离级别，此时一个视图read-view A也创建了），这是一个很长的事务……

事务A在今天上午9:20的时候，查询了一个记录R1的一个字段f1的值为1……
今天上午9:25的时候，一个事务B（随之而来的read-view B）也被开启了，它更新了R1.f1的值为2（同时也创建了一个由2到1的回滚日志），这是一个短事务，事务随后就被commit了。
今天上午9:30的时候，一个事务C（随之而来的read-view C）也被开启了，它更新了R1.f1的值为3（同时也创建了一个由3到2的回滚日志），这是一个短事务，事务随后就被commit了。
……
到了下午3:00了，长事务A还没有commit，为了保证事务在执行期间看到的数据在前后必须是一致的，那些老的事务视图、回滚日志就必须存在了，这就占用了大量的存储空间。
源于此，我们应该尽量不要使用长事务。