一致性视图是啥时候建立的?
数据库运维
数据库事务的一致性视图是啥时候建立的?这个问题还比较重要,如果没搞清楚,可能会影响我们做实验的结果,进而得出错误的结论,所以今天松哥和大家简单聊一聊这个话题。

 

在上篇文章中涉及到了一个小小的问题,就是数据库事务的一致性视图是啥时候建立的?

这个问题还比较重要,如果没搞清楚,可能会影响我们做实验的结果,进而得出错误的结论,所以今天松哥和大家简单聊一聊这个话题。

1. 错误演示

先给大家来一个错误演示。

我们打开两个会话窗口,默认情况下隔离级别是可重复读,我们来看下:

首先在 A 会话中查看当前 user 表,查看完成后开启事务:

可以看到当前 age 是 101。

接下来在 B 会话中修改 age:

可以看到,B 会话已经修改成功。

接下来回到 A 会话查询记录:

可以看到,A 会话的记录也变了。完整测试流程如下:

说好的可重复读呢?

按理说,可重复读就是别的事务对数据的操作不影响当前事务,但是上面这个案例似乎和我们理解的可重复读有出入。

2. 分析

不知道小伙伴们是否还记得可重复读的特点:

用户在另外一个事务中执行同条 SELECT 语句数次,结果总是相同的。

从这个角度来说,第一小节的案例似乎也没有问题,因为我们在 A 会话中执行 SELECT 语句多次,查到的结果也都是相同的,age 都是 102。

但是我们疑惑的是明明 B 会话的事务后开启的,但是我们却在 A 会话中读取到了 B 的修改,这似乎不应该。

这里就涉及到一个问题,事务的一致性视图是何时建立的?

事实上,我们执行的 begin 语句并不是一个事务真正的起点。执行完 begin 之后,接下来执行的第一句 SQL,事务才真正启动。

我们稍微修改一下第一小节的案例:

在 A 会话中,事务开启之后,立马先执行一条 SELECT 语句,然后再去 B 会话中做修改,修改完成后再回到 A 会话继续查询,此时发现 B 中的修改对 A 并不可见,这个结果也符合用户在另外一个事务中执行同条 SELECT 语句数次,结果总是相同的。

如果我们想要执行完 begin 之后,就立马开启事务,那么可以通过如下方式来执行:

  1. start transaction with consistent snapshot; 

这个 SQL 执行完之后,事务立马就启动了。

接下来,回到第一小节的案例,我们修改一下事务启动的命令:

此时,A 会话中事务的查询就看不见 B 中的修改了。

3.小结

好啦,一个小小的案例,希望小伙伴们在做实验的时候不要出错。本文涉及到一个概念叫做一致性视图,如果大家不熟悉可以参考上篇文章。

责任编辑:武晓燕 来源: 江南一点雨

同话题下的热门内容

访问数据库总超时?这份避坑指南请收好数据库文件损坏并且无备份,不用慌!DB Repair修复工具利器是时候检查一下使用索引的姿势是否正确了!Sentry 开发者贡献指南-数据库迁移

编辑推荐

Oracle免费的便捷Web应用开发框架二则从携程系统瘫痪,看国内企业数据管理乱象数据库update时这样干,你就悲剧了携程事件反思:是该重视数据库灾备了!四种优秀的数据库设计工具
我收藏的内容
点赞
收藏