在PostgreSQL中，页面修剪主要是针对堆表中的什么数据进行的？
A
对于任何快照都不再可见的元组（即xmax < snapshot.xmin）
B
对于当前快照仍可见的元组
C
仅由活动事务修改的元组
D
所有元组
📌 正确答案：A
对于任何快照都不再可见的元组（即 xmax < snapshot.xmin）
📖 核心机制解析： 修剪目标
页面修剪会自动删除堆表页面中在任何活跃事务的快照中均不可见的死元组（Dead Tuples）。这些元组通常由已提交的DELETE或UPDATE操作产生，其xmax（删除事务ID）小于当前所有快照的最小事务ID（snapshot.xmin），因此不可能被任何当前或未来事务访问。 触发时机
当SQL操作（如SELECT、UPDATE、INSERT、DELETE）访问堆表页面时，若检测到页面空间不足（例如剩余空间低于fillfactor参数阈值）或页面被标记为PD_PAGE_FULL，则会触发修剪。
例如：若页面填充因子（fillfactor）设为75%，当数据占用超过该比例时，更新操作可能触发修剪以释放空间。 作用范围与限制
仅限当前页面：修剪仅在当前堆表页面内部进行，不跨页面操作，因此效率较高。
不更新全局结构：修剪不会更新空闲空间映射（FSM）或可见性映射（VM），释放的空间仅能被同一页面的更新操作重用，无法用于插入新元组。
保留指针：若死元组被索引引用，其行指针（Line Pointer）仍会保留，但标记为可重用。
🔄 与其他机制的对比： 与VACUUM的区别：
VACUUM会跨页面全局清理死元组、更新FSM/VM、删除索引项等，而页面修剪是轻量级的即时局部清理，仅发生在查询访问页面时。 与HOT更新的关联：
若更新操作满足HOT条件（未修改索引列且新元组可插入同一页面），修剪会回收旧元组空间，避免创建新索引项，提升效率。
⚠️ 错误选项排除： B（当前快照仍可见的元组）：可见元组是有效数据，不会被修剪。
C（仅由活动事务修改的元组）：活动事务修改的元组可能尚未提交，仍对其他事务可见，不属于修剪范围。
D（所有元组）：修剪仅针对死元组，活动元组会被保留。
💎 总结：
页面修剪是PostgreSQL的实时空间回收机制，核心目标是高效释放堆表页面中已失效的元组空间（xmax < snapshot.xmin），确保更新操作能重用本地存储，减少碎片化。其轻量化、局部化的特性使其成为VACUUM的重要补充，共同维护数据库性能。
