并发事务问题
脏读
概念: 一个事务读到另外一个事务还没提交的数据
举例:
事务A:第一步:select 第二步:update 第三步:...
事务B:第一步:select 第二步:...
假设原本在数据库中的 数据C = 1,那么
- 事务A进行到第二步修改了数据库中的 数据C =2
- 此时事务B开始第一步,读取事务A修改后的 数据C=2
- 但是此时事务A未将事务提交,有可能会进行事务的回滚,数据C 被修改回原来的值 =1
- 而事务B此时持有的就是错误的 数据C =2
不可重复复
概念: 一个事务先后读取同一条记录,但两次读取到的数据不同
举例:
事务A:第一步:select 第二步:... 第三步:select
事务B:第一步:... 第二步:update 第三步:提交事务
- 事务A执行到第一步,查询 数据C =1
- 接着事务B 执行到第二步,修改了数据C =2
- 接着事务B 执行到第三步,提交了事务
- 接着事务A执行到第三步,再次查询数据C =2
- 但此时事务A发现,前后两次查询数据C的值不一样,这就出现了 不可重复读
幻读
概念: 一个事务按照查询条件查询数据时,没有对应的数据行,但是在插入数据时,又发现这行数据已经存在
举例:
事务A:第一步:select 第二步:insert 第三步:select
事务B:第一步:... 第二步:insert 第三步:提交事务
- 事务A要插入一条 id=1 的数据,第一步先查询数据库中是否有 id=1 的数据,发现没数据
- 接下来事务B 刚好执行到第二步,插入了一条 id=1 的数据
- 事务B执行到第三步,提交了事务
- 而事务A此时进行到第二步,要往数据库中插入 id=1 的数据,结果发现已经存在了
- 但是事务A接着执行第三步查询,结果查询到的结果还是没有
事务隔离级别设置方法
查看事务隔离级别
sql
SELECT @@TRANSACTION_ISOLATION;
设置事务隔离级别
sql
SET [ SESSION | GLOBAL ] TRANSACTION ISOLATION LEVEL { READ UNCOMMITTED |
READ COMMITTED | REPEATABLE READ | SERIALIZABLE }
其中的 [ SESSION | GLOBAL ] 选择是只对当前会话进行设置还是对全局进行设置
事务隔离级别详解
读未提交(Read uncommitted)
效果 -- 相当于没有隔离,三种并发事务问题都会发生
虽然 读未提交的隔离级别 的数据安全性最差,但是性能最高,因为其并发程度最高
读已提交(Read committed)
Oracle的默认隔离级别
效果 -- 解决了脏读问题
例如上面的脏读例子:
事务A:第一步:select 第二步:update 第三步:提交
事务B:第一步:select 第二步:... 第三步:select
假设原本在数据库中的 数据C = 1,那么
- 事务A进行到第二步修改了数据库中的 数据C = 2
- 此时事务B开始第一步,读取的不再是事务A修改后的 数据C ,而是原本的值 数据C=1
- 等事务A将事务提交
- 事务B再次读取 数据C,才会读取到事务A修改的 数据C=2
这就解决了脏读问题
可重复读
MySQL的默认隔离级别
效果 -- 解决了 脏读、不可重复读 问题
例如上面的不可重复读例子:
事务A:第一步:select 第二步:... 第三步:select
事务B:第一步:... 第二步:update 第三步:提交事务
- 事务A执行到第一步,查询 数据C =1
- 接着事务B 执行到第二步,修改了数据C =2
- 接着事务B 执行到第三步,提交了事务
- 接着事务A执行到第三步,再次查询到的不是事务B已经提交的数据C=2,还是之前的C=1
这就解决了不可重复读的问题
串行化
效果 -- 解决了 脏读、不可重复读、幻读 问题
串行化就是同步,不存在并发,那肯定就没有并发事务问题
但是没有并发,也就意味着,串行化对性能的影响很大
举例:
事务A:第一步:select 第二步:insert 第三步:select
事务B:第一步:insert 第二步:... 第三步:提交事务
- 事务A要插入一条 id=1 的数据,第一步先查询数据库中是否有 id=1 的数据,发现没数据
- 接下来事务B 刚要开始执行第一步插入id=1的数据,但是此时因为事务A在进行,事务B不能并发,会被阻塞
- 必须等事务A进行到第二步,要往数据库中插入 id=1 的数据,接着执行后面的步骤直到提交事务
- 事务A提交后,事务B才会开始进行第一步,但是这个时候事务B就会发现id=1的数据已经存在,插入失败
这就解决了幻读的问题
总结
事务隔离级别越高,数据越安全,但是性能越低