4.清理(vacuum)-01.docx
50墨值下载
由于 PostgreSQL MVCC 机制的特殊性，对于更新或删除频繁的表，会累积大量过期数据，
占用大量磁盘，并且由于需要扫描更多数据，使得查询性能降低。
PostgreSQL 解决该问题的方式是使用 VACUUM。从释放磁盘的角度，VACUUM 分为两种
1. VACUUM：该操作不要求获得排它锁，因此它可以和其它的读写表操作并行进行。
同时它只是简单的将 dead tuple 对应的磁盘空间标记为可用状态，新的数据可以重用
这部分磁盘空间。但是这部分磁盘并不会被真正释放，也不会被交还给操作系统，因
此不能被系统中其它程序所使用，并且可能会产生磁盘碎片。
2. VACUUM FULL：需要获得排它锁，它将所有有效数据（非 dead tuple）复制到新
的磁盘文件中，并将原数据文件全部删除，并将未使用的磁盘空间还给操作系统，因
此系统中其它进程可使用该空间，并且不会因此产生磁盘碎片。
VACUUM
Vacuum 过程如下：
1. 删除死元组及指向死元组的索引元组
2. 冻结旧的事务 ID（txid）
3. 移除提交日志（clog）中非必需的部分
4. 更新 FSM，VM，以及统计信息
1.删除死元组
0 页面包含三条元组， 其中 Tuple_2 是死元组，如图(1)所示。PostgreSQL 移除了
Tuple_2，并重排剩余元组来整理碎片空间，如图(2)所示。 PostgreSQL 不断重复该过程直
至最后一页。
注意：非必需的行指针是不会被移除的，它们会在将来被重用。因为如果移除了行指针，就必
须同时更新所有相关索引中的索引元组。
2.冻结旧的事务 ID
冻结分为两种模式：惰性模式（lazy mode）和迫切模式（eager mode）。
1. 惰性模式下，冻结使用目标表对应的 VM 扫描包含死元组的页面。
2. 迫切模式下，它会扫描所有的页面，无论其是否包含死元组，它还会更新与冻结处理
相关的系统视图，并在可能的情况下删除不必要的 clog。
冻结旧的事务 ID，需要计算当前 txid 与元组 t_xmin 的值，计算公式为：当前 txid - 元组
t_xmin>vacuum_freeze_min_age（默认值为 5000 万）
惰性模式
举个例子，如果在执行 VACUUM 命令时，还有其他三个事务正在运行，且其 txid 分别为
100,101,102，那么当前 txid 就是 100。
例子：表由三个页面组成，每个页面包含三条元组。 执行 VACUUM 命令时，当前 txid 为
50,002,500。经过计算元组 t_xmin 最大值为 2500，小于 2500 的元组将被冻结。冻结步骤如
下：
1. 第 0 页：三条元组被冻结，因为所有元组的 t_xmin 值都小于 2500。此外，因为
Tuple_1 是一条死元组，因而在该清理过程中被移除。
2. 第 1 页：通过查看可见性映射（从 VM 中发现该页面所有元组都可见），清理跳过了
对该页面的清理。
3. 第 2 页：Tuple_7 和 Tuple_8 被冻结，且 Tuple_7 被移除。
在完成清理之前，与清理相关的统计数据会被更新，例如 pg_stat_all_tables 视图中的
n_live_tup，n_dead_tup，last_vacuum，vacuum_count 等字段。
因为惰性模式可能会跳过页面，所以它无法冻结所有需要冻结的元组。
迫切模式
迫切模式弥补了惰性模式的缺陷。它会扫描所有页面，检查表中的所有元组，更新相关的系统
视图，并在可能时删除非必需的 clog 文件与页面。
当满足以下条件时，会执行迫切模式：当前 txid - pg_database.datfrozenxid >
vacuum_freeze_table_age（默认为 150,000,000）
pg_database.datfrozenxid 保存着每个数据库中最老的已冻结的事务标识。
例子：执行 VACUUM 命令时的事务 ID 为 150,002,000，因此，当前 txid=150,002,000，
经过计算元组 t_xmin 最大值为 100,002,000，小于 100,002,000 的元组将被冻结。因为当前
txid(150002000)-1821 > 150000000) ，因而冻结以迫切模式执行，如下所示。
of 14
50墨值下载
【版权声明】本文为墨天轮用户原创内容，转载时必须标注文档的来源（墨天轮），文档链接，文档作者等基本信息，否则作者和墨天轮有权追究责任。如果您发现墨天轮中有涉嫌抄袭或者侵权的内容，欢迎发送邮件至：contact@modb.pro进行举报，并提供相关证据，一经查实，墨天轮将立刻删除相关内容。
下载排行榜
评论