03 事务隔离

03 事务隔离

事务:保证一组数据库操作,要么全部成功,要么全部失败。在 MySQL 中,事务支持是在引擎层实现的。

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


建议你尽量不要使用长事务。****

读未提交(read uncommitted)、读提交(read committed)、可重复读(repeatable read)和串行化(serializable )

值得注意的是,隔离得越严实,效率就会越低。

读未提交:一个事务还没提交时,它做的变更就能被别的事务看到。
读提交:一个事务提交之后,它做的变更才会被其他事务看到。
可重复读:一个事务执行过程中看到的数据,总是跟这个事务在启动时看到的数据是一致的,未提交变更对其他事务也是不可见的。
串行化:对于同一行记录,“写”会加“写锁”,“读”会加“读锁”。当出现读写锁冲突的时候,后访问的事务必须等前一个事务执行完成,才能继续执行。
  1. 若隔离级别是“读未提交”, V1 是 2。这时候事务 B 虽然还没有提交,但是结果已经被 A 看到了。因此,V2、V3 也都是 2。
  2. 若隔离级别是“读提交”,V1 是 1,V2 是 2。事务 B 的更新在提交后才能被 A 看到。所以, V3是 2。
  3. 若隔离级别是“可重复读”,则 V1、V2 是 1,V3 是 2。V2 还是 1,事务在执行期间看到的数据前后必须是一致的
  4. 若隔离级别是“串行化”, V1、V2 值是 1,V3 的值是 2。事务A一开始查询值1的时候就获得了读锁,根据两阶段加锁,事务A获得的锁要在commit的时候才释放,所以事务B在修改1为2的时候申请写锁会阻塞直到事务A提交事务A提交之前获取的值都是1,所以V1 V2都是1,事务A提交后事务B获取到写锁完成更新操作,所以V3是2

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

MySQL 的事务启动方式:
  1. 显式启动事务语句:begin 或 start transaction。配套的提交语句是 commit,回滚语句是 rollback。
  2. set autocommit=0,这个命令会将这个线程的自动提交关掉。意味着如果你只执行一个 select 语句,这个事务就启动了,而且并不会自动提交。这个事务持续存在直到你主动执行 commit 或 rollback 语句,或者断开连接。

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


问:如何避免长事务对业务的影响?

答:

从应用开发端来看

  1. 确认是否使用了 set autocommit=0。
  2. 确认是否有不必要的只读事务。
  3. 业务连接数据库的时候,通过 SET MAX_EXECUTION_TIME 命令,控制每个语句执行的最长时间,避免单个语句意外执行太长时间。

从数据库端来看

  1. 监控 information_schema.Innodb_trx 表,设置长事务阈值,超过就报警 / 或者 kill;
  2. Percona 的 pt-kill 工具不错;
  3. 在业务功能测试阶段要求输出所有的 general_log,分析日志行为提前发现问题;
  4. MySQL 5.6 或者更新版本,把 innodb_undo_tablespaces 设置成 2(或更大的值)。如果真的出现大事务导致回滚段过大,这样设置后清理起来更方便。

热门相关:走私大明   重开地狱   虎狼之师   最牛兵王   护花猎王