[[442041]]kaiyun官方网站

在上篇著作中触及到了一个小小的问题，即是数据库事务的一致性视图是啥技巧竖立的?

这个问题还相比蹙迫，若是没搞剖判，可能会影响咱们作念执行的恶果，进而得出失误的论断，是以今天松哥和天下浅薄聊一聊这个话题。

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 之后，就立马开缘起务，那么不错通过如下面孔来扩展：

start transaction with consistent snapshot; 

这个 SQL 扩展完之后，事务立马就运行了。

接下来，回到第一末节的案例，咱们修改一下事务运行的高歌：

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

3.小结

好啦kaiyun官方网站，一个小小的案例，但愿小伙伴们在作念执行的技巧不要出错。本文触及到一个认识叫作念一致性视图，若是天下不熟练不错参考上篇著作。