postgresql子查询共享事务快照，其可见性由mvcc机制决定而非嵌套位置；无论深度如何，子查询均只能看到事务开始时已提交的数据版本，无法访问本事务未提交或并发事务未提交的写入。
PostgreSQL 14 中的子查询本身不“处理”多版本并发写入，它只是读取数据的语法结构；真正决定可见性的，是 MVCC 机制和事务快照。子查询能否看到某次写入，完全取决于它所在的事务快照是否包含该写入事务的提交状态。
子查询看到的数据由事务快照决定，不是由子查询位置决定
在 SELECT 中嵌套子查询（比如 WHERE x IN (SELECT ...) 或 FROM (SELECT ...) AS t），子查询执行时使用的快照，和外层查询完全一致——它们共享同一个事务开始时刻生成的快照。这意味着：
- 子查询绝不会看到本事务未提交的写入，哪怕外层 UPDATE 已执行、子查询在之后运行
- 子查询也绝不会看到其他并发事务尚未提交的写入，无论子查询嵌套多深
-
EXISTS子查询和IN子查询在可见性上无本质区别，差异只在语义和执行计划 - 如果子查询被提升为物化（例如因
enable_material开启且代价估算有利），它仍基于同一快照，不会“重新捕获”新提交的数据
UPDATE/DELETE 中的子查询可能引发意外可见性问题
当子查询出现在 UPDATE 或 DELETE 的 WHERE 条件中（例如 UPDATE t SET x=1 WHERE id IN (SELECT id FROM s WHERE ...)），需特别注意行版本可见性与目标行锁定之间的交互：
- 子查询部分读取的是快照数据，但
UPDATE本身会对匹配到的目标行加ROW EXCLUSIVE锁，并检查这些行的当前xmax：若已被其他事务删除（xmax ≠ 0且已提交），则跳过 - 若子查询依赖的表与被更新表是同一张表，且子查询条件涉及未提交的本事务修改（如
UPDATE t SET a=a+1 WHERE id IN (SELECT id FROM t WHERE a > 10)），PostgreSQL 会按快照语义执行——即子查询看到的是事务开始时的版本，不是本事务已改但未提交的中间状态 - 这种“快照隔离 + 行级锁”的组合，可能导致看似矛盾的结果：子查询返回了某行 ID，但
UPDATE实际没改那行，因为该行在加锁时已被其他事务抢先更新或删除
避免子查询与并发写入冲突的实操建议
多数问题出在逻辑假设与 MVCC 行为不匹配。以下做法可降低风险：
- 不要在子查询中依赖“刚 INSERT 的数据”来驱动后续 UPDATE/DELETE，除非显式
COMMIT后另起事务——因为子查询看不到本事务未提交的插入 - 对关键业务逻辑，用
SELECT ... FOR UPDATE显式锁定子查询结果集，再执行更新，确保读取与修改之间无干扰 - 慎用
WITH ... AS MATERIALIZED（PG 12+）包装子查询：它强制物化结果，但物化时刻仍受限于当前快照，不会绕过 MVCC 规则 - 若需强一致性（如金融类场景），将隔离级别升至
REPEATABLE READ或SERIALIZABLE，但要注意SERIALIZABLE可能触发could not serialize access due to read/write dependencies错误，需应用层重试
容易被忽略的底层细节
很多人以为子查询“重新查一次表”，就能看到最新数据。实际上：
- 所有 SQL 语句（含子查询）在执行前都绑定到一个固定快照，这个快照在事务
BEGIN时确定，不会随时间推移自动刷新 -
txid_current()返回当前事务 ID，但子查询中调用它并不能改变快照；而txid_snapshot()可以查看当前快照范围，用于调试可见性问题 - 系统列如
xmin、xmax在子查询中可直接 SELECT，是验证某行是否对该子查询可见的最直接手段 - VACUUM 延迟会导致 dead tuple 积压，虽然不影响子查询可见性判断，但会拖慢子查询扫描性能——尤其当子查询走全表扫描时
