一致性快照是MVCC下动态构建的逻辑视图，非独立实体；事务启动时确立版本视图，基于xmin/xmax过滤可见行；版本存于物理页的行版本链中；VACUUM/PURGE后台清理不可见旧版本，受长事务、配置不当及复制延迟影响。
SQL数据库的一致性快照（Consistent Snapshot）并非数据库原生“生成”的独立实体，而是事务隔离级别（尤其是可重复读 RR 和串行化 SERIALIZABLE）下，通过多版本并发控制（MVCC）机制在查询执行时动态构建的、反映某一时间点全局一致数据状态的逻辑视图。它不占用额外磁盘空间存储完整副本，其“生成”与“回收”本质是内存中版本元数据的维护与清理过程。
快照如何被“生成”——实际是事务启动时的版本视图确立
当一个事务以 REPEATABLE READ 或更高隔离级别开始时，数据库引擎（如 PostgreSQL、MySQL InnoDB）会为该事务分配一个唯一的事务 ID（XID），并记录当前活跃事务列表（snapshot）。这个 snapshot 不是复制数据，而是：
- 记录事务开始时刻所有已提交事务的最大 ID（xmin）和所有尚未结束事务的 ID 列表（xmax）
- 每个数据行头包含创建该版本的事务 ID（xmin）和使之失效的事务 ID（xmax）
- 查询时，引擎根据当前事务的 snapshot 过滤行：仅返回 xmin ≤ 当前事务 ID 且 (xmax = 0 或 xmax > 当前事务 ID) 的可见版本
版本数据从哪里来——物理存储中的行版本链
实际数据版本存于表的物理页中（如 PostgreSQL 的 heap page，InnoDB 的聚簇索引页）。每次 UPDATE/DELETE 并非覆盖原行，而是：
- UPDATE：插入新版本行，并将旧行的 xmax 设为当前事务 ID
- DELETE：仅标记旧行 xmax 为当前事务 ID，不立即移除物理数据
- 所有历史版本行与当前行共存于同一表空间，靠事务 ID 和可见性规则区分
快照何时被“回收”——VACUUM / PURGE 的触发与作用
旧版本行不会自动消失，必须由后台进程清理，否则导致膨胀（bloat）和性能下降。回收依赖两个关键条件：
- 无任何活跃事务需要访问该版本：即该版本的 xmin 小于系统中所有活跃事务的最小 XID（oldest xmin）
- 对应事务已提交或回滚：只有已终止事务产生的版本才可被安全回收
具体机制因引擎而异：
-
PostgreSQL：由 VACUUM 扫描表页，识别并移除不可见的死亡元组（dead tuples），重用空间；autovacuum 自动触发，但需合理配置
vacuum_cost_delay和vacuum_scale_factor -
MySQL InnoDB：由后台线程 PURGE 持续清理 undo log 中已不再被任何 snapshot 引用的旧版本；undo 表空间大小和
innodb_purge_threads影响回收效率
影响快照生命周期的关键配置与行为
以下操作会显著延长旧版本存活时间，阻碍回收：
- 长时间运行的事务（如未提交的 SELECT、大事务批处理）：会拖住全局 oldest xmin，导致大量版本无法清理
- 未启用或配置不当的 autovacuum（PG）或 purge 线程过少（MySQL）
- Replication slot（PG）或 long-running replica（MySQL binlog dump）未及时消费，使主库保留旧 WAL/undo 以供同步
- 显式使用
SET TRANSACTION ISOLATION LEVEL REPEATABLE READ启动事务后长期空闲，同样锁定 snapshot
