SQL数据库中数据可见性由事务隔离级别和MVCC共同决定，核心是事务启动时生成的动态快照，通过事务ID、xmin/xmax及活跃事务列表判断行版本可见性；Read Committed每次查询新建快照，Repeatable Read/Serializable复用首次快照。
SQL数据库中数据可见性由事务隔离级别和多版本并发控制（MVCC）机制共同决定，核心在于每个事务在执行时看到的是一致的“快照”——即该事务开始时刻已提交的数据状态。这个快照不是静态复制，而是通过事务ID、行版本标记与可见性判断逻辑动态生成的。
事务视图（Transaction View）的构成
每个事务启动时，数据库会为其分配一个唯一的事务ID（如 PostgreSQL 的 xid），并生成一个“快照”，记录当时所有活跃事务的ID集合。该快照包含：
- 当前事务ID：用于标识本事务的写入是否对其他事务可见
- 快照范围：最小未分配事务ID（xmin）、最大已结束事务ID（xmax）
- 活跃事务列表：启动时仍在运行的事务ID列表，用于判断这些事务的修改是否可见
行版本可见性判断逻辑（以MVCC为例）
读取某一行时，数据库检查其两个系统字段（如 PostgreSQL 的 xmin 和 xmax）：
- xmin 是插入该行的事务ID：若 xmin 在快照中已提交且不在活跃列表中，且 xmin ≤ 当前事务ID，则插入可见
- xmax 是删除/更新该行的事务ID：若 xmax 为0（未删除）或 xmax 不在快照活跃列表中且 xmax ≥ 当前事务ID，则该行未被逻辑删除
- 更新操作实际是插入新版本+标记旧版本 xmax，因此同一行可能有多个版本，仅最新有效版本对当前事务可见
不同隔离级别的视图生成差异
隔离级别不改变单个事务内部的快照逻辑，而是影响快照生成时机和范围：
- Read Committed：每次执行 SELECT 都生成新快照，只能看到语句开始前已提交的数据
- Repeatable Read / Serializable：事务第一次查询时生成快照，后续查询复用该快照，保证结果一致性
- Serializable 还额外检测写偏序等异常，可能触发串行化失败重试
实际影响与调试提示
常见现象背后都是视图逻辑在起作用：
- 同一事务内多次 SELECT 结果相同 → 复用初始快照
- 事务A看不到事务B刚 COMMIT 的数据 → 因为A的快照生成早于B的提交时间
- 长事务导致旧版本无法清理（bloat）→ 其快照持续存在，阻止 vacuum 清理 xmin 早于它的行版本
可通过系统视图（如 PostgreSQL 的 pg_snapshot 或 pg_stat_activity）查看当前事务快照信息，辅助分析不可见数据原因。
