冲突可串行化

冲突操作不能随意交换：一次写若跨过另一个事务的读，读到的值可能改变；两次写互换则最终写者可能改变。非冲突的相邻操作可以逐步交换。若这些交换最终能把每个事务的操作聚成连续块，就得到了串行调度。

前驱图把大量操作压成事务级约束。边 $T_1\to T_2$ 不是说两个事务在墙钟上完全不重叠，只说任何冲突等价的串行解释都必须把 $T_1$ 放在 $T_2$ 前。

这个抽象刻意不分析写入函数是否交换。两次都写常数 0 仍是写写冲突，因为一般判据只看访问类型；若系统要利用加法交换或集合并集等语义，必须采用有证明的语义并发控制，而不能悄悄从标准图中删边。

考虑

r1(x); w1(x);
r2(x); w2(y);
r3(y); w3(z);
c1; c2; c3

$x$ 上的写—读给出 $T_1\to T_2$，$y$ 上的写—读给出 $T_2\to T_3$。图无环，唯一受约束的顺序为 $T_1,T_2,T_3$；w3(z) 与前面不访问 $z$ 的操作可跨事务交换，不会增加边。

另一个调度

r1(x); r2(y); w1(y); w2(x); c1; c2

在 $y$ 上产生 $T_2\to T_1$，在 $x$ 上产生 $T_1\to T_2$，形成二环。即使最终数值偶然与某次串行执行相同，冲突判据仍拒绝它，因为这种偶然相等不是对所有初值与事务计算都稳定的等价证据。

冲突可串行化不是全部视图可串行化。盲写可能制造冲突环，却不改变任何读来源或最终写者；这类严格更宽的历史由 视图可串行化公理库视图可串行化View serializability · View-serializable schedule以初值读取、读取来源和最终写者保持来定义调度的视图等价，并覆盖部分含盲写的非冲突串行历史。 处理。反过来，图无环只回答隔离次序，不回答读了未提交值后能否安全提交。

构图时读—写方向也不能合并。$r_i(x)<w_j(x)$ 给出 $T_i\to T_j$，而 $w_j(x)<r_i(x)$ 给出相反边并可能改变读值；用“两个事务都访问 x”生成无向边，会同时丢失串行次序和环的方向证据。

构图算法可逐项扫描调度，对同一数据项的跨事务读写和写写对加入边，再做拓扑排序。实现若锁的是范围或谓词，图的“数据项”也必须覆盖幻读冲突；只按现有行 ID 构图会漏掉插入的新行。

两阶段锁等协议通过限制锁的取得与释放，让所有冲突边服从某个锁点顺序。它们提供的是充分生成机制，不是图判定的定义。对包含中止的执行，还需先说明被撤销操作怎样从逻辑调度中消除；环检测本身不会执行 undo。

在线检测可以在每次加入边后维护增量有向无环图；发现成环时中止某个尚未提交事务。选择哪个事务是代价策略，不影响判据。若环上的事务都已向外确认提交，检测已经太晚，系统不能靠事后任选一个回滚来补造串行历史。