PostgreSQL技术内幕22:vacuum full 和 vacuum

文章目录

0.简介

在之前介绍MVCC文章中介绍过常见的MVCC实现的两种方式,一种是将旧数据放到回滚段,一种是直接生成一条新数据(对于删除是不删除),PG采用的是第二种,虽然实现上较为清晰简单,但面临着数据膨胀的问题。本文将介绍其清理命令vacuum,主要包含概念和使用方式,以及实现原理。

1.概念及使用方式

vacuum是一个SQL命令,可以进行垃圾回收并选择性的分析数据库,其语法如下,主要看full和analyze,full的作用下面会详细介绍,analyze的作用就是同时收集表内容的统计信息,结果放在pg_statistic系统目录中,然后查询计划就能使用这个信息去制定高效的计划。

cpp 复制代码
VACUUM [ ( option [, ...] ) ] [ table_and_columns [, ...] ]
VACUUM [ FULL ] [ FREEZE ] [ VERBOSE ] [ ANALYZE ] [ table_and_columns [, ...] ]

where option can be one of:

    FULL [ boolean ]
    FREEZE [ boolean ]
    VERBOSE [ boolean ]
    ANALYZE [ boolean ]
    DISABLE_PAGE_SKIPPING [ boolean ]
    SKIP_LOCKED [ boolean ]
    INDEX_CLEANUP { AUTO | ON | OFF }
    PROCESS_MAIN [ boolean ]
    PROCESS_TOAST [ boolean ]
    TRUNCATE [ boolean ]
    PARALLEL integer
    SKIP_DATABASE_STATS [ boolean ]
    ONLY_DATABASE_STATS [ boolean ]
    BUFFER_USAGE_LIMIT size

and table_and_columns is:

    table_name [ ( column_name [, ...] ) ]

2.工作原理

2.1 主要功能

1)清理失效元组。

2)生成分析数据

3)更新VM(visibility map)。

4) 防止事务id环绕。

2.2 清理流程

其流程如下:

  1. 清理失效元组第一步是要识别出那些是失效元组,在之前的MVCC中介绍过,其有xmin和xmax,xmax表示被那个事务删除,如果已经提交了且没有小于xmax的事务继续执行,那么就说明这个元组失效,知道怎么查找失效元组后我们看清理步骤。
    找到dead tuples后会构建该表的dead tuples的链表,该链表存储在缓存中,然后会去移除dead tuples指向的index。这步也就是先清理index。
  2. 移除完index后就需要开始处理其本身,在这不使用vacuum和vacuum full存在区别,vacuum只是去把dead tuples的部分标记为可重用空间然后整理其剩余元组将其重新排列,也就是表的实际空间并没有减少,只是可以重用了;而vacuum full是将目标表有效tuples拷贝到新表中然后删除目标表,然后重建索引。
  3. 删除完dead tuples后就需要更新VM和FSM,这两个的作用在前面文章PG逻辑存储层级和物理存储结构中有描述。
  4. 最后就是可以更新统计信息及相关系统表。

2.3 防止事务id环绕说明

PG的事务id是32位的,最多就是2的32次方,也就是4294967296,所以其采用的是循环利用的方式,同时MVCC是比较依赖事务ID,如果插入的XID大于当前事务XID的行版本,那么就是将来的事务,对当前事务不可见。有以上两个基础,不难想象如果运行足够长的时间,xid计数器会变为0,可能会导致所有以前的数据都被认为是未来的,也就是所有数据都看不到(这只是事务id回卷的一种场景),PG解决这种场景的方式是通过vacuum,识别存在很长时间的数据将其记录为FREEZE,这些数据不遵循XID比较原则,对所有事务可见。

3.使用建议

可以看见Vacuum比较于Vacuum full有着更快的执行速度,但其不能减小膨胀后的空间,运行时FREEZE很老的记录。而Vacuum full能回收更多空间,但其运行缓慢,运行后所有记录都被FREEZE,其需要全程加独占锁,不推荐生产环境使用。

处理上述两种主动清理,PG还支持字段清理,即Autovacuum,其可以根据需要设置使用在晚上(使用较少时)执行清理,尽可能减少影响。

相关推荐
曾凡宇先生10 分钟前
openEuler安装jdk,nginx,redis
linux·开发语言·数据库·openeuler
点灯小铭23 分钟前
基于单片机的四沟道步进电机玉米补种机设计与实现
数据库·单片机·嵌入式硬件·毕业设计·课程设计·期末大作业
清风66666633 分钟前
基于单片机的双机串口通信与数字串存储系统设计
数据库·单片机·mongodb·毕业设计·课程设计·期末大作业
数据库知识分享者小北42 分钟前
AI Agent越用越笨?阿里云AnalyticDB「AI上下文工程」一招破解!
数据库
一匹电信狗1 小时前
【MySQL】数据库表的操作
linux·运维·服务器·数据库·mysql·ubuntu·小程序
api_180079054601 小时前
性能优化揭秘:将淘宝商品 API 响应时间从 500ms 优化到 50ms 的技术实践
大数据·数据库·性能优化·数据挖掘
白衣鸽子1 小时前
MySQL 时间类型深度解析:精度、时区陷阱与版本兼容
数据库·后端·mysql
冲上云霄的Jayden1 小时前
MySQL InnoDB 状态(SHOW ENGINE INNODB STATUS)深度分析与性能优化建议
数据库·mysql·性能优化·innodb
元闰子3 小时前
怎么让程序更高效地连起来?
数据库·redis·mysql
洲覆3 小时前
Redis 内存淘汰策略
开发语言·数据库·redis·缓存