DBMS 事务和可序列化

Posted

技术标签:

【中文标题】DBMS 事务和可序列化【英文标题】:DBMS Transaction and Serializable 【发布时间】:2015-01-17 08:22:07 【问题描述】:

我们知道:

一种日程安排,其中事务以这样一种方式对齐,即 事务首先执行。当第一笔交易完成时 它的周期然后执行下一个事务。交易是有序的 一个接一个。这种类型的调度称为串行调度 交易以串行方式执行。

如果两个事务是相互的,则此执行不会造成任何损害 独立并处理不同的数据段,但如果这些 两个事务处理相同的数据,结果可能不同

那么发现两个事务是 Serialize Schedule 的好处是什么?如果结果不同,有什么好处?

【问题讨论】:

“本次执行”是指事务的串行执行还是事务的非串行执行? (第二次引用之前发生了什么?) 【参考方案1】:

当事务访问相同的变量但串行执行(即不同时执行)时,与只有一个事务执行(可能重复)时相比,“结果可能会有所不同”。对于串行事务,我们不知道(非重叠)事务的执行顺序。我们在重复事务执行开始时所知道的是,自上次执行结束以来其他事务可能已经更改了变量重复交易。 (尽管我们通常了解一些关于他们是如何离开的。)

这种“变化的结果”并没有错,因为它们只是反映了交易是在不同的时间被请求的。

当事务访问相同的变量并同时执行(即非串行)时,那么对于每个事务,“结果可能会有所不同”(从另一种意义上说)与我们通常理解代码的方式不同。这种正常的理解依赖于一次只执行一个事务。例如,通常如果代码读取一个变量两次而不写入它,那么我们期望得到相同的值。但是,如果另一个事务在读取之间写入它,则不能保证。例如,通常如果代码读取一个变量,那么我们期望得到该变量实际具有的值。但是,如果我们得到它的一些字节,然后另一个事务写入它,然后我们从那个新值中得到其余的字节,这并不能保证。

但是如果事务是可序列化的,那么它们可以非串行执行(有重叠),但结果与串行执行(没有重叠)相同。那么代码就是只有一个事务在执行时的正常含义。

所以我们必须确保系统的行为就像交易是串行的,否则我们不知道我们的程序做了什么

可序列化调度是来自多个事务的操作的交错,它给出与某些序列化(化)调度相同的结果。 执行可序列化调度与仅执行一个事务的所有操作一个接一个地执行另一个操作不同的好处是通过同时执行多个事务的多个操作来提高吞吐量。

PS

您的报价出现在web page 上,这是一团糟。它甚至没有定义“可序列化的时间表”。你的引文之间的文字是

在多事务环境中,串行调度被视为 基准。事务中指令的执行顺序 不能更改,但两个交易可以有它们的指令 以随机方式执行。

但是第二句应该开始但是在一个非串行的时间表中......。因为在 serial 调度中,“事务是一个接一个地排序的”。因此,报价中的“结果可能会有所不同”是在非连续时间表中

但是你没有回复我的评论:

“本次执行”是指交易的连续执行还是 非串行执行事务? (在你之前发生了什么 第二个报价?)

【讨论】:

亲爱的@Philips,所以我们检查并看到两个事务被序列化。如果我们运行 T1,然后运行 ​​T2,我们得到结果 1(并且正确)。如果我们运行 T2,然后运行 ​​T1,我们会得到结果 2(并且错误)。但是我们不确定 DBMS 可能在这个序列化计划中首先运行 T1 或 T2,在这种情况下,序列化有什么好处? 我们假设交易发生在不同的时间,具有“不同的结果”(意义 1)。但我们不能任意重叠交易,否则我们会得到“不同的结果”(意义 2)。可序列化的调度就像串行事务一样,所以它的重叠是可以的。而且它可以更快。你混淆了“不同结果”的感觉;意义 1 是不可避免的(不是“错误的”);必须避免感觉 2。 (请参阅我编辑的答案。)

以上是关于DBMS 事务和可序列化的主要内容,如果未能解决你的问题,请参考以下文章

Redis事务

MySQL基础——事务隔离级别

关于分布式事务

关于分布式事务

事务及其特性ACID

MySQL事务和锁