【华为云技术分享】初识MySQL隔离级别

我们知道MySQL有四种不同的隔离级别,分别是:read-uncommit、read-commit、repeat-read和serializable。这四种隔离级别分别解决了不同的数据一致性问题,也存在不同的问题。

可以通过MySQL的下列参数来设置不同的隔离级别:

transaction-isolation = {READ-UNCOMMITTED | READ-COMMITTED | REPEATABLE-READ | SERIALIZABLE}

read-uncommitted

该隔离级别下允许一个事务读取到其它事务未提交的写操作,比如下面事务trx 1在t2时刻读到了事务trx 2的修改结果,但是事务trx2并没有提交,我们称这种现象为脏读。脏读对事务
没有任何意义,我们应该尽量的避免

a=1;
trx 1                  --------------------           trx 2
begin;                                                begin;
(t1) select a; -> a==1
                                                      update a=2;
(t2) select a; -> a==2
                                                      rollback
commit;

read-committed

此隔离级别下解决了事务的脏读问题, 比如下面事务trx 2在t2时刻已经将a修改为2但没有提交,事务trx 1读到的仍然是a=1。在t3时刻事务trx2提交了修改,事务trx1读到了修改的结果a==2。

a=1;
trx 1                  --------------------           trx 2
begin;                                                begin;
(t1) select a; -> a==1
                                                      update a=2;
(t2) select a; -> a==1
                                                      commit;
(t3) select a; -> a==2
commit;

虽然read-committed解决了脏读的问题,但是依然存在幻读的问题。如下所示,初始时a有两条记录(1,10),t2时刻事务2**了一条a=5的记录但是没有提交,事务1读到的是(1,10)两条记录。

在t3时刻事务2已经提交,此时事务1读到的是(1,5,10)3条记录。此问题被称为幻读,也称做不可重复读。

a=(1,10);
trx 1                  --------------------           trx 2
begin;                                                begin;
(t1) select a>0; -> a==(1,10)
                                                      insert a=5;
(t2) select a>0; -> a==(1,10)
                                                      commit;
(t3) select a>0; -> a==(1,5,10)
commit;

repeated-read

该隔离级别下解决了脏读和幻读的问题,如下t2时刻事务2**了一条a=5的记录但是没有提交,事务1读到的是(1,10)两条记录。在t3时刻事务2已经提交,此时事务1依然读到的是(1,10)2条记录

a=(1,10);
trx 1                  --------------------           trx 2
begin;                                                begin;
(t1) select a>0; -> a==(1,10)
                                                      insert a=5;
(t2) select a>0; -> a==(1,10)
                                                      commit;
(t3) select a>0; -> a==(1,10)
commit;

该隔离级别存在的问题是lost update,该问题的发送场景如下:

a=1;
trx 1                  --------------------           trx 2
begin;                                                begin;
(t1) @val1 = select a; -> @val1==1
(t2)                                                  @val2 = select a; -> @val2==1
                                                      set a=@val2+1;
(t3)                                                  commit;   -->  a=2
set a=@val1+2;
(t4) commit; --> a=3

t1,t2时刻事务trx1、trx2分别读到了a为1,t3时刻事务2将它修改成a+1=2并行提交,t4时刻事务1将它修改成a+2=3。最终a的值为3,为事务1的修改结果,事务2的修改结果就丢失了。这种情况
称为lost update。

serializable

该隔离级别下很好的解决了lost udpate的问题,上面同样的两个事务执行过程如下:

a=1;
trx 1                  --------------------           trx 2
begin;                                                begin;
(t1) @val1 = select a; -> @val1==1
(t2)                                                  @val2 = select a;  // block阻塞
set a=@val1+2;
(t3) commit; --> a=3
                                                      @val2==3
                                                      set a=@val2+1;
(t4)                                                  commit;   -->  a=4

如上所示,t2时刻事务2读取a的值是发生了阻塞等待,因为此时事务1正在读取a的值。直到t3时刻事务1提交完成,事务2才能读到a的值,结果为@val2==3,是事务1的修改结果。接下来事务2将它修改
成a+1=4。事务1和事务2对a的修改都最终体现在了a的终值上面。

总结:

MySQL提供了四种不同的隔离级别,分别是:read-uncommit、read-commit、repeated-read和serializable,后三种隔离级别分别结果了脏读、幻读、lost update的问题。虽然serializable解决了全部
的问题,但是实际运行时它的性能是最差的。所以日常生产环境中我们一般使用read-commit、repeated-read两种隔离级别,既能解决一些严重的不一致问题又能保持MySQL比较高的性能。

原文地址:https://www.cnblogs.com/2020-zhy-jzoj/p/13164779.html