前言:整理归纳,个人温习之用,请支持正版极客时间
1、何谓事务?
2、隔离性与隔离级别
-
脏读:当数据库中一个事务A正在修改一个数据但是还未提交或者回滚,另一个事务B 来读取了修改后的内容并且使用了,之后事务A提交了。此情况仅会发生在: 读未提交的隔离级别
-
不可重复读(虚读):在一个事务A中多次操作数据,在事务A操作过程中(未最终提交),事务B也做了处理,并且该值发生了改变,这时候就会导致A在事务操作的时候,发现数据与第一次不一样了。此情况仅会发生在:读未提交、读提交的隔离级别
-
幻读:第一个事务对一个表中的数据进行了修改,这种修改涉及到表中的全部数据行。同时,第二个事务也修改这个表中的数据,这种修改是向表中插入一行新数据。那么,以后就会发生操作第一个事务的用户发现表中还有没有修改的数据行,就好象发生了幻觉一样。此情况会回发生在:读未提交、读提交、可重复读的隔离级别。解决幻读的方法是增加范围锁RangeS,锁定检索范围为只读。
-
读未提交:一个事务还没提交时,它做的变更就能被别的事务看到
-
读提交:一个事务提交之后,它做的变更才会被其他事务看到
-
可重复读:一个事务执行过程中看到的数据,总是跟这个事务在启动时看到的数据是一致的。当然在可重复读隔离级别下,未提交变更对其他事务也是不可见的
-
串行化:顾名思义是对于同一行记录,“写”会加“写锁”,“读”会加“读锁”。当出现读写锁冲突的时候,后访问的事务必须等前一个事务执行完成,才能继续执行。
mysql> create table T(c int) engine=InnoDB;
insert into T(c) values(1);
-
“读未提交”: V1 的值就是 2。这时候事务 B 虽然还没有提交,但是结果已经被 A 看到了,V2、V3 也都是 2
-
“读提交”: V1 是 1,V2 的值是 2。事务 B 的更新在提交后才能被 A 看到, V3 的值也是 2
-
“可重复读”: V1、V2 是 1,V3 是 2。之所以 V2 还是 1,遵循的就是这个要求:事务在执行期间看到的数据前后必须是一致的
-
“串行化”:在事务 B 执行“将 1 改成 2”的时候,会被锁住。直到事务 A 提交后,事务 B 才可以继续执行。所以从 A 的角度看, V1、V2 值是 1,V3 的值是 2。
-
“读提交”隔离级别下,这个视图是在每个 SQL 语句开始执行的时候创建的。
-
“读未提交”隔离级别下直接返回记录上的最新值,没有视图概念
-
“可重复读”隔离级别下,这个视图是在事务启动时创建的,整个事务存在期间都用这个视图(静态,不受其它事物更新的影响)
-
“串行化”隔离级别下直接用加锁的方式来避免并行访问
3、事务隔离的实现
4、事务的启动方式
-
显式启动事务语句, begin 或 start transaction。配套的提交语句是 commit,回滚语句是 rollback
-
set autocommit=0,这个命令会将这个线程的自动提交关掉。意味着如果你只执行一个 select 语句,这个事务就启动了,而且并不会自动提交。这个事务持续存在直到你主动执行 commit 或 rollback 语句,或者断开连接。
5、总结
-
首先,从应用开发端来看:确认是否使用了 set autocommit=0。这个确认工作可以在测试环境中开展,把 MySQL 的 general_log 开起来,然后随便跑一个业务逻辑,通过 general_log 的日志来确认。一般框架如果会设置这个值,也就会提供参数来控制行为,你的目标就是把它改成 1。确认是否有不必要的只读事务。有些框架会习惯不管什么语句先用 begin/commit 框起来。我见过有些业务并没有这个需要,但是也把好几个 select 语句放到了事务中。这种只读事务可以去掉。业务连接数据库的时候,根据业务本身的预估,通过 SET MAX_EXECUTION_TIME 命令,来控制每个语句执行的最长时间,避免单个语句意外执行太长时间。(为什么会意外?在后续的文章中会提到这类案例)
-
其次,从数据库端来看:监控 information_schema.Innodb_trx 表,设置长事务阈值,超过就报警 / 或者 kill;Percona 的 pt-kill 这个工具不错,推荐使用;在业务功能测试阶段要求输出所有的 general_log,分析日志行为提前发现问题;如果使用的是 MySQL 5.6 或者更新版本,把 innodb_undo_tablespaces 设置成 2(或更大的值)。如果真的出现大事务导致回滚段过大,这样设置后清理起来更方便。