元组可见性由t_xmin、t_xmax与事务快照共同决定，需满足插入事务可见且删除事务不可见；通过hint bits、VM和freeze机制优化判断效率并防止回卷问题。
PostgreSQL 使用 MVCC（多版本并发控制）机制来管理数据的并发访问，确保事务之间互不干扰的同时提供一致的数据视图。元组可见性是 MVCC 的核心概念之一，决定了某个事务是否能看到某一行数据（即元组）。判断一个元组是否对当前事务可见，依赖于元组的系统字段和当前事务的状态。
元组可见性依赖的关键系统字段
每个元组包含以下四个关键的系统字段，用于判断其可见性：
- t_xmin：插入该元组的事务 ID
- t_xmax：删除或更新该元组的事务 ID
- t_ctid：指向元组的物理位置，用于链式更新追踪
- t_infomask：包含事务提交状态、命令号等元信息（内部使用）
PostgreSQL 判断元组是否可见时，结合当前事务的快照（Transaction Snapshot）进行评估。事务快照记录了在事务开始时所有正在运行的事务列表，以及 xmin 和 xmax 范围。
基本可见性规则
对于当前事务来说，判断一个元组是否可见，遵循以下逻辑：
1. 如果 t_xmin > 当前事务的快照 xmin说明插入该元组的事务是在当前事务开始之后才启动的，因此该元组对当前事务不可见。
2. 如果 t_xmin 是未提交事务且不在快照的活跃事务列表中，并且已提交需要检查该事务最终是否提交。如果已提交，则可能可见（还需进一步判断）；如果被回滚，则该元组无效。
3. 如果 t_xmax 为 0表示该元组未被删除或更新，只要 t_xmin 可见，该元组就可见。
4. 如果 t_xmax 非 0- 若 t_xmax 对应的事务已提交，则该元组已被删除或被新版本取代，对当前事务不可见
- 若 t_xmax 对应的事务未提交或在快照中仍为活跃事务，则该元组仍可能可见
UPDATE 操作会标记旧元组的 t_xmax 为当前事务 ID，并插入一个新元组（t_xmin 为当前事务 ID）。新元组是否可见，按上述规则判断。旧元组即使被“删除”，只要其 t_xmax 未提交，在某些事务中仍可见。
事务快照的作用
事务启动时，PostgreSQL 会生成一个快照（SnapshotData），包含：
- xmin：当前系统中最老的尚未结束的事务 ID（即还在运行的最小事务 ID）
- xmax：下一个将要分配的事务 ID
- xip_list：在事务开始时仍在运行的事务 ID 列表
判断可见性的标准流程：
- 若 t_xmin
- 若 t_xmax ≠ 0：
- 若 t_xmax
- 若 t_xmax 在 xip_list 中 → 删除者仍在运行 → 元组仍可见
简而言之：一个元组只有在其插入事务对当前事务“可见”且删除事务对当前事务“不可见”或未发生时，才是可见的。
特殊情况与优化
为了提升可见性判断效率，PostgreSQL 引入了以下机制：
Hint Bits在元组头中设置 hint bits，标记事务是否已提交或回滚，避免每次都要查询事务状态日志（clog）。
Visibility Map (VM)标识哪些数据页中的所有元组都对所有事务可见，可用于 VACUUM 跳过清理，也支持 index-only scans。
Freeze 和事务ID回卷处理
为防止事务 ID 回卷造成可见性混乱，PostgreSQL 使用 VACUUM FREEZE 将很老的事务标记为“冻结事务”，视为永远已提交。
基本上就这些。理解元组可见性有助于排查“幻读”现象、分析长事务影响，以及优化 vacuum 策略。掌握 xmin、xmax 与事务快照的关系，是深入理解 PostgreSQL 并发控制的基础。
