视图可串行化

视图等价像比较两次演出中观众真正看见的接力关系。每位读者拿到的是哪位写者交出的值，开场前的初值由谁读到，落幕时最后一笔是谁写下，这三类观察相同即可。后台两次没人读取的写入先后可能变化，而不影响这份视图。

这种宽容带来计算代价。冲突图把每个可能改变语义的操作对都固定成边，容易检查但有时过于保守；视图判定要猜一个串行顺序，再核对读来源与最终写者，盲写使许多候选无法由局部边直接排除。

三项条件各守一扇门：initial-read 防止把本应读数据库初态的操作放到某个写者之后；reads-from 固定事务之间的数据依赖；final-write 固定外部最终能看见谁的版本。删除任一项都能构造错误的“等价”顺序。

事务 $T_1$ 对 $x$ 连续执行两次盲写，$T_2$ 执行一次盲写。考虑操作序列

w1(x,1); w2(x,2); w1(x,3)

冲突图既有 $T_1\to T_2$，也有 $T_2\to T_1$，所以它不冲突可串行化。然而序列没有读操作，最终写者是 $T_1$；串行次序 $T_2,T_1$ 同样以 $T_1$ 的第二次写结束。因此两者的初值读取、reads-from 与最终写者全部相同，原调度视图可串行化。

若在 $w_2(x,2)$ 后加入 $r_3(x)\to 2$，串行见证还必须把 $T_3$ 安排在能从 $T_2$ 读取的位置；只比较最终值 $3$ 已不够。反过来，两个不同写者碰巧都写数值 $0$，也不能因为字节相同就把 reads-from 来源混为一谈。

这里讨论的是逻辑读写。触发器、谓词查询和多版本读取会改变“同一个写”的身份；必须先正规化事件与版本。提交失败的事务是否保留在视图中也要预先约定，通常对已提交投影判断串行性，再由恢复条件处理中止效果。

“最终数据库相同”远弱于视图等价。若 $T_2$ 根据读值向外返回审批结果，即使后续盲写把数据库恢复成相同字节，客户端已经观察到的 reads-from 仍不同。最终状态测试无法覆盖事务返回值和控制分支。

视图可串行化给出比冲突判据更宽的正确历史集合，却很少直接作为在线调度器的完整判定目标。系统更常采用锁、时间戳或验证协议生成易证的子类，因为在每次提交处解决一般 NP-complete 搜索并不现实。

盲写密集的批量装载或覆盖更新最能暴露两种定义的差别。审计器若只报告冲突环，应把结论写成“不是冲突可串行化”，不能直接升级为“没有任何串行视图”；若要作后一判断，必须给出三项视图条件或一个不可能性证明。

工程系统常用冲突可串行化作为可执行保证，再把视图理论用于解释这份保证为何保守。若要利用更宽集合提升并发，协议必须维护足以证明读来源和最终写者的状态；“某次测试结果一样”不是可复用的调度规则。