无级联事务调度

可恢复调度允许先借未兑现支票，只要求借款人晚些承诺；无级联调度干脆等支票兑现后才交给下游。这样一个事务中止时，影响停在本事务，不会沿读取链把一串工作推倒。

代价是等待或旧版本。单版本锁系统让读者阻塞到写者结束；多版本系统可以让读者选择更早的已提交版本。二者都能无级联，却呈现不同延迟与可见性。

所以“读没有阻塞”不否定无级联。关键是读到的版本是否已提交，而不是当前是否另有写者。版本链让活跃写者与旧版读者并存，单版本实现则更可能把同一条件表现为等待。

调度

w1(x,20); c1; r2(x)->20; c2

满足无级联条件。若 $T_1$ 在 $c_1$ 前中止，$T_2$ 尚未读到它的值；若 $T_2$ 已读，则 $T_1$ 的提交决定已经固定。与之相比，$w_1(x);r_2(x);c_1;c_2$ 虽可恢复，却仍让 $T_2$ 在 $T_1$ abort 时被迫回滚。

下面的调度没有任何跨事务读，因而无级联条件真空成立：

w1(x,1); w2(x,2); c2; c1

但 $T_2$ 覆盖了 $T_1$ 尚未提交的写，所以它不是 严格事务调度公理库严格事务调度Strict transaction schedule · Strict schedule在写者提交或中止前禁止其他事务读取或覆盖其写入项，从而同时排除脏读与脏写。。这个反例说明“不会级联中止”不能改写成“任何人都不接触未提交数据”。

在 MVCC 中，$T_2$ 可能在 $T_1$ 活跃时读取更老的已提交版本。物理上两者并发访问同一键，逻辑 reads-from 却不指向 $T_1$；判断应跟随版本来源，而不是仅看键名和墙钟重叠。

无级联也不禁止事务根据旧的已提交值作决定。若业务要求读取“当前最新”，还需定义快照时点或串行顺序；本性质只排除未提交来源，不能保证数据新鲜，也不能阻止长事务持续读取很老的合法版本。

无级联执行让事务 abort 的逻辑影响局部化，显著简化恢复与客户端错误处理。许多数据库通过严格锁、提交可见性规则或多版本读视图实现这一性质，但各机制还会附带不同串行性与阻塞保证。

它不消除死锁，也不保证提交事务可串行化。两个事务可以只读已提交旧值，分别写不同数据项并共同破坏约束；避免脏读与排除 write skew 属于不同历史条件。

恢复层可以利用这一性质缩小 abort 影响集：中止事务无需遍历读依赖去寻找跟随者。但写写冲突仍需保留足够 before-image，串行化控制仍需检查跨项依赖。无级联只删去一类恢复责任，不是完整恢复算法。

实际 trace 审计应为每次读记录版本创建事务与其 commit LSN，再验证提交先于读事件。只记录“读值等于 20”会在不同事务写出相同数值时丢失来源，无法证明 ACA 条件。