为何不统一采用方案2处理Serializable Snapshot Isolation过时前提检测？

你提到的这个问题核心在于两种方案的性能开销、冲突精度和实现复杂度差异——并不是第二种方案不能覆盖第一种场景，而是第一种方案在特定场景下有不可替代的优势，下面具体拆解：

• 性能开销的针对性优化
  第一种方案只需要跟踪当前事务读取时跳过的特定未提交写入（比如某条具体记录的写入事务），不需要维护任何范围级别的元数据。而第二种方案要为每个读取的索引范围建立跟踪，还要监控该范围内所有后续写入，这会带来额外的内存开销和检查成本。对于单条记录读取这类简单场景，第一种方案的开销要小得多，不会因为过度跟踪降低系统并发度。

• 冲突检测的精度更高
  第一种方案的冲突是明确且直接的：当前事务读取快照时，存在一个未提交的写入修改了同一条记录，当当前事务提交时，需要检查这个写入是否已经提交——如果是，说明当前事务的读取结果已经过时。而第二种方案的范围跟踪会把范围内所有写入都视为潜在冲突，哪怕这些写入和当前事务的实际读取内容无关（比如你读了ID=5，范围跟踪覆盖ID=1-10，ID=7的写入会被误判为冲突），这会导致不必要的冲突检测甚至事务回滚，降低了实际的并发能力。

• MVCC基础上的渐进式实现
  SSI是基于MVCC快照隔离的增强，第一种方案其实是对MVCC现有机制的最小扩展：MVCC本来就会记录未提交事务的写入信息，第一种方案只是在提交阶段多做一步校验——确认当初读取时跳过的未提交写入是否已经影响当前结果。而第二种方案需要额外构建一套谓词锁（predicate locking）或类似的范围监控机制，实现复杂度更高。很多数据库是从快照隔离逐步升级到SSI的，第一种方案可以快速实现基础的Serializable能力，再按需扩展第二种方案覆盖范围型冲突。

简言之，第二种方案确实能覆盖第一种场景，但代价过高。第一种方案在处理单记录的“读取前未提交写入”场景时，更轻量、精准，能在保证Serializable的前提下最大化并发；第二种方案则用来处理更复杂的范围读取冲突。两者结合是权衡性能和正确性的最优解，而非单一方案更简洁。

内容的提问来源于stack exchange，提问作者Jack Peng