事务隔离:为什么你改了我还看不见?

ACID (Atomicity、Consistency、Isolation、Durability)即原子性、一致性、隔离性、持久性。

当数据库上有多个事务同时执行的时候,就可能会出现脏读(dirty read)、不可重复读(nonrepeatable read)、幻读(phantom read)的问题。

隔离级别

SQL标准的隔离级别包括:读未提交(read uncommitted)、读提交(read committed)、可重复度(repeatable read)和串行化(serializable)。

  • 读未提交:一个事务还没有提交时,它做的变更就能被别的事务看到。

  • 读提交:一个事务提交之后,它做的变更才会被其他事务看到。

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

  • 串行化:对同一条记录“写”会加“写锁”,“读”会加“读锁”。当出现读写冲突的时候,后访问的事务必须等待前一个事务执行完成,才能继续执行。

事务隔离的实现

数据库隔离的实现上会创建一个视图,访问的时候以视图的逻辑结果为准。

“可重复读”隔离级别下,这个视图是在事务启动时创建的,整个事务存在期间都会用这个视图。

“读提交”隔离级别下,这个视图是在每个SQL语句开始执行的时候创建的

**“读未提交”**隔离级别下直接返回记录上的最新值,没有视图的概念

“串行化”的隔离级别下直接使用加锁的方式避免并行访问

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

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

当前值是 4,但是在查询这条记录的时候,不同时刻启动的事务会有不同的 read-view。如图中看到的,在视图 A、B、C 里面,这一个记录的值分别是 1、2、4,同一条记录在系统中可以存在多个版本,就是数据库的多版本并发控制(MVCC)。对于 read-view A,要得到 1,就必须将当前值依次执行图中所有的回滚操作得到。

同时你会发现,即使现在有另外一个事务正在将 4 改成 5,这个事务跟 read-view A、B、C 对应的事务是不会冲突的。

回滚日志系统会判断,当系统中没有比这个回滚日志更早的read-view的时候,日志会被删除。

建议不要使用长事务

长事务意味着系统里面会存在很老的事务视图,由于这些事务随时可能访问数据库里面的任何数据,所以这个事务提交之前,数据库里面它可能用到的回滚记录都必须保留,这就会导致大量占用存储空间。

长事务还会占用锁资源,也可能拖垮整个库。

通过以下语句可以查询持续时间超过60s的事务。

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

事务的启动方式

  1. 显式启动,begin或start transaction。配套的提交语句是commit,回滚语句是commit

  2. set autocommit=0,这个命令会将这个线程自动提交关闭。意味着如果你只执行select语句,这个事务就启动了,而且不会自动提交。这个事务持续存在直到你主动执行commit或rollback语句,或者断开连接。

建议使用set autocommit=1,通过显式语句的方式启动事务。

在 autocommit 为 1 的情况下,用 begin 显式启动的事务,如果执行 commit 则提交事务。如果执行 commit work and chain,则是提交事务并自动启动下一个事务,这样也省去了再次执行 begin 语句的开销。同时带来的好处是从程序开发的角度明确地知道每个语句是否处于事务中。

Licensed under CC BY-NC-SA 4.0
陕ICP备16008414号
使用 Hugo 构建
主题 StackJimmy 设计