postgres--表的行布局

最新推荐文章于 2025-05-23 17:03:50 发布

IT艺术家-rookie

最新推荐文章于 2025-05-23 17:03:50 发布

阅读量973

点赞数 24

分类专栏：数据库技术文章标签：数据库

本文链接：https://blog.csdn.net/newbieJ/article/details/147553209

版权

数据库技术专栏收录该内容

16 篇文章

订阅专栏

HeapTupleHeaderData

它表中每一行（元组）的固定头部结构，包含了行版本控制、事务信息等重要元数据。以下是对其各字段的通俗解释：

1. 事务控制字段

t_xmin (4字节)

记录插入该行的事务ID。只有当事务提交后，其他事务才能看到此行。
举例：事务100插入了这行数据，该字段值就是100。

t_xmax (4字节)

记录删除/更新该行的事务ID。默认值为0（未删除）。
举例：事务200删除了这行，该字段变为200。如果是更新操作，PostgreSQL会标记旧行为已删除，并插入新行。

t_cid / t_xvac (4字节)

t_cid：事务内的命令ID（用于事务回滚时定位操作）。
t_xvac：VACUUM 操作的事务ID（仅在特殊清理场景使用）。

2. 行版本指针

t_ctid (6字节)

指向当前行版本或新版本的物理位置（由页号和行偏移组成）。
举例：更新操作后，旧行的t_ctid会指向新行，形成版本链。

3. 元数据标志位

t_infomask2 (2字节)

低11位：记录列的数量。
高5位：标志位（如是否有空值、外部TOAST存储等）。

t_infomask (2字节)

关键状态标志位，例如：

HEAP_HASNULL：是否有空值（决定是否有空值位图）。
HEAP_HASOID_OLD：是否包含对象OID（旧版本兼容）。
HEAP_XMIN_COMMITTED：插入事务是否已提交。

4. 数据定位字段

t_hoff (1字节)

用户数据的起始偏移量（需按MAXALIGN对齐）。
举例：若t_hoff=24，表示跳过23字节的头部后，从第24字节开始是实际数据。

数据存储结构

固定头部
固定23字节（不同平台可能对齐不同），包含上述事务和标志信息。
空值位图（可选）
如果t_infomask包含HEAP_HASNULL，会有一个位图标记哪些列是NULL。
举例：3列的表，位图0b110表示第2列为NULL。
对象ID（可选）OID介绍
旧版本中若包含OID（HEAP_HASOID_OLD），会在此处存储。，OID（Object Identifier，对象标识符）是一个用于唯一标识数据库内部对象的整型数值。它是 PostgreSQL 系统目录（System Catalogs）中追踪和管理对象的核心机制
用户数据
从t_hoff开始，按列顺序存储。变长字段（如TEXT）可能引用TOAST表。

关键机制

MVCC（多版本并发控制）

通过t_xmin和t_xmax实现：未提交的事务对他人不可见，已删除的行仅对特定事务可见。

行版本链

PostgreSQL 的版本链机制通过 t_ctid 字段实现，它是 MVCC（多版本并发控制）的核心设计之一。更新操作通过t_ctid形成链式结构，支持事务隔离和回滚。

`t_ctid` 的作用

定义：t_ctid 是一个 物理地址指针，结构为 (页号, 行偏移)（例如 (0,1) 表示第 0 页的第 1 行）。
核心规则：

未更新的行：t_ctid 指向自己（表示这是最新版本）。
更新后的旧行：t_ctid 指向新版本的位置。
新生成的行：t_ctid 指向自己（新的最新版本）。

版本链的构建过程

假设有一个初始行 id=1, value='A'，逐步更新到 value='B' 和 value='C'。以下是物理存储中的变化：

初始插入（事务100）

物理存储：

页0, 行1: [t_xmin=100, t_xmax=0, t_ctid=(0,1), value='A']

t_ctid=(0,1)：指向自己，表示这是最新版本。

第一次更新（事务200）

生成新版本：

页0, 行2: [t_xmin=200, t_xmax=0, t_ctid=(0,2), value='B']

旧版本标记：
```
页0, 行1: [t_xmin=100, t_xmax=200, t_ctid=(0,2), value='A']
```
◦ t_xmax=200：事务200删除了旧版本。

◦ t_ctid=(0,2)：指向新版本的位置。

第二次更新（事务300）

生成新版本：

页0, 行3: [t_xmin=300, t_xmax=0, t_ctid=(0,3), value='C']

前一个新版本标记：
```
页0, 行2: [t_xmin=200, t_xmax=300, t_ctid=(0,3), value='B']
```
◦ t_xmax=300：事务300删除了这个版本。

◦ t_ctid=(0,3)：指向最新版本。

版本链的最终形态

所有版本通过 t_ctid 形成链式结构：

页0,行1 → 页0,行2 → 页0,行3
  (A)       (B)       (C)

• 旧版本：行1 和 行2 的 t_xmax 不为0，表示已被删除。

• 最新版本：行3 的 t_xmax=0，表示有效。

查询时的遍历逻辑

当一个事务（例如事务250）读取 id=1 时：

从索引找到初始指针：假设索引指向 页0,行1。
检查可见性：
• 行1 的 t_xmin=100（已提交），但 t_xmax=200（事务200是否提交？）。

若事务200已提交 → 该行对事务250不可见，需沿 t_ctid=(0,2) 跳转到 行2。
检查下一版本：
• 行2 的 t_xmin=200（是否已提交？），t_xmax=300（事务300是否提交？）。

若事务200已提交，事务300未提交 → 事务250看到 value='B'。
如果事务300已提交：
• 继续沿 t_ctid=(0,3) 跳转到 行3，最终看到 value='C'。

关键特性

• 旧版本不立即删除：只有执行 VACUUM 后，旧版本占用的空间才会被回收。

• HOT（Heap Only Tuple）优化：如果更新不涉及索引字段，新版本可能存放在同一页的空闲空间，避免更新索引（t_ctid 链仅在堆表中跳转，索引仍指向旧版本）。

通过 SQL 观察 `t_ctid`

你可以直接查询 ctid 字段查看物理地址：

SELECT ctid, xmin, xmax, * FROM your_table WHERE id = 1;

输出示例：

 ctid  | xmin | xmax | id | value
-------+------+------+----+-------
 (0,1) | 100  | 200  | 1  | A
 (0,2) | 200  | 300  | 1  | B
 (0,3) | 300  | 0    | 1  | C

• xmin：插入该版本的事务ID。

• xmax：删除该版本的事务ID（0表示未删除）。

• ctid：当前行的物理地址（或指向新版本的地址）。

总结

• t_ctid 的本质：是旧版本指向新版本的物理地址指针，形成单向链表。

• 版本链的意义：实现 MVCC，让不同事务看到不同的数据快照。

• 存储代价：更新越频繁，版本链越长，需合理配置 autovacuum 防止表膨胀。

对齐与压缩

MAXALIGN确保数据按CPU字长对齐；变长字段可能被压缩或存储到TOAST表。

实际应用场景

• 排查事务冲突

通过t_xmin和t_xmax分析行被哪个事务锁定或修改。

• 优化存储

减少NULL列可省略空值位图；避免使用OID节省空间。

• 理解查询计划

索引扫描通过t_ctid快速定位行，回表操作依赖头部信息。

示例：一行数据的物理布局

| t_xmin | t_xmax | t_ctid | t_infomask2 | t_infomask | t_hoff | [NULL位图] | [OID] | 列1数据 | 列2数据... |

• 若某行由事务100插入，被事务200更新，则：

• 旧行t_xmax=200，t_ctid指向新行位置。

• 新行t_xmin=200，t_xmax=0（未被删除）。

UPDATE 操作的底层行为

PostgreSQL 在执行 UPDATE 操作时，底层会生成新的行版本（称为多版本并发控制，MVCC），旧版本的行不会被立即删除。这种设计虽然提高了并发性能，但会导致存储空间的占用，直到旧版本被清理。以下是详细机制和影响：

生成新行版本（新元组）

新元组写入：PostgreSQL 会在表中插入一个新的行版本，包含更新后的数据。
旧元组保留：旧版本的行会被标记为失效（通过设置 t_xmax 字段），但物理上仍然保留在磁盘上。

版本链的形成

t_ctid 指针：旧行的 t_ctid 字段会指向新行的物理位置（(page_number, item_offset)），形成版本链。
读操作可见性：事务根据 t_xmin 和 t_xmax 判断哪个版本对它可见。

过一些特殊的系统列（System Columns）和扩展工具`HeapTupleHeaderData` 直接或间接查看部分关键信息

直接通过 SQL 查看系统列

PostgreSQL 为每个表隐式定义了几个系统列，可通过显式查询获取：

-- 查看行的 xmin, xmax, ctid 等关键信息
SELECT 
  xmin,       -- 插入该行的事务ID (对应 HeapTupleHeaderData.t_xmin)
  xmax,       -- 删除/锁定该行的事务ID (对应 HeapTupleHeaderData.t_xmax)
  ctid,       -- 行的物理位置 (对应 HeapTupleHeaderData.t_ctid)
  tableoid,   -- 表的OID
  oid         -- 行的对象ID（若表启用了 WITH OIDS）
FROM your_table;

示例输出：

  xmin  | xmax | ctid  | tableoid | oid  
--------+------+-------+----------+------
 100001 |    0 | (0,1) |    16384 | 1234

xmin=100001: 此行由事务ID 100001插入。
xmax=0: 未被删除或锁定。
ctid=(0,1): 位于第0页的第1行。

使用 `pageinspect` 扩展查看底层细节

pageinspect 是 PostgreSQL 官方扩展，可解析页面存储的二进制内容，直接查看 HeapTupleHeaderData 的详细信息。

步骤 1: 安装扩展

CREATE EXTENSION pageinspect;  -- 需超级用户权限

步骤 2: 查看页面的元组头信息

-- 查看指定页面的所有元组头信息（包括 t_infomask, t_infomask2）
SELECT 
  lp          AS item_offset, -- 行在页内的偏移量
  t_xmin, 
  t_xmax, 
  t_ctid,
  t_infomask, 
  t_infomask2,
  t_hoff      AS header_size  -- 用户数据起始偏移
FROM heap_page_items(get_raw_page('your_table', 0)); -- 0表示第0页

示例输出：

 item_offset | t_xmin | t_xmax | t_ctid | t_infomask | t_infomask2 | header_size 
-------------+--------+--------+--------+------------+-------------+-------------
           1 | 100001 |      0 | (0,1)  |       2306 |           2 |          24

t_infomask=2306: 转化为二进制 0000100100000010，根据标志位含义：

• HEAP_XMIN_COMMITTED（已提交的插入事务）

• HEAP_HASVARWIDTH（包含变长字段）
t_infomask2=2: 表示有2列数据（低11位）。

解析标志位 (t_infomask 和 t_infomask2)

虽然无法直接通过 SQL 函数解析标志位，但可通过位运算结合文档判断状态。例如：

判断是否包含 NULL 值

-- 检查 t_infomask 是否包含 HEAP_HASNULL (0x0001)
SELECT (t_infomask & 1) != 0 AS has_nulls
FROM heap_page_items(get_raw_page('your_table', 0));

判断行是否被锁定

-- 检查 t_infomask 是否包含 HEAP_XMAX_IS_MULTI (行被多个事务锁定)
SELECT (t_infomask & 0x1000) != 0 AS is_multi_locked
FROM heap_page_items(get_raw_page('your_table', 0));

其他工具

• pgrowlocks 扩展：查看行级锁信息。

CREATE EXTENSION pgrowlocks;
SELECT * FROM pgrowlocks('your_table');

• 日志分析：通过设置 log_statement = 'all' 跟踪事务操作。

注意事项

权限要求：使用 pageinspect 和系统函数需超级用户权限。
性能影响：get_raw_page 直接读取磁盘页面，避免在生产环境频繁使用。
版本兼容性：不同 PostgreSQL 版本的存储格式可能略有差异。

总结

• 基础信息：直接通过 xmin, xmax, ctid 系统列查看事务和存储位置。

• 底层细节：使用 pageinspect 解析 t_infomask、t_infomask2 等字段。

• 标志位解析：通过位运算或参考官方文档手动解码。

实际的开发指导意义

事务设计与并发控制

避免长事务导致的存储膨胀

问题：未提交的事务会阻止 VACUUM 清理旧版本（t_xmin/t_xmax 未被释放）。

解决方案：

监控长事务：

SELECT pid, query_start, state, xact_start 
FROM pg_stat_activity 
WHERE state = 'idle in transaction' OR xact_start < NOW() - INTERVAL '1 hour';

• 优化事务粒度：避免在事务中执行耗时操作，拆分为小事务。

理解 MVCC 的可见性

读操作不阻塞写操作：通过 t_xmin 和 t_xmax 判断数据可见性。
应用场景：在高并发场景下，合理选择事务隔离级别（如 READ COMMITTED 或 REPEATABLE READ）。

存储优化

减少 NULL 字段的存储开销

机制：t_infomask 的 HEAP_HASNULL 标志决定是否存储 NULL 位图。
优化建议：

避免设计大量可为 NULL 的字段，用默认值替代。

使用紧凑的数据类型（如 SMALLINT 替代 INT）。

避免不必要的 OID

机制：HEAP_HASOID_OLD 标志决定是否存储对象 OID。
优化建议：

• 建表时显式指定 WITHOUT OIDS（默认已禁用）：
```
CREATE TABLE my_table (id SERIAL, data TEXT) WITHOUT OIDS;
```

性能调优

利用 HOT（Heap-Only Tuple）更新

机制：如果更新不修改索引字段，新版本可能存储在同一页，索引无需更新。
优化方法：

• 调整 fillfactor：预留页空间给 HOT 更新：
```
ALTER TABLE my_table SET (fillfactor = 80);  -- 每页预留20%空闲空间
```
• 分离常更新字段：将频繁修改的字段拆分到单独表。

减少版本链遍历开销

问题：版本链过长会导致查询需要多次跳转（通过 t_ctid）。
优化方法：

• 定期执行 VACUUM：清理旧版本，缩短版本链。

• 避免频繁更新同一行：例如计数器用 RETURNING 或乐观锁。

4. 故障排查与监控

诊断表膨胀

查询死元组占比：

SELECT 
  relname,
  n_live_tup AS live_rows,
  n_dead_tup AS dead_rows,
  (n_dead_tup::FLOAT / (n_live_tup + n_dead_tup)) * 100 AS dead_pct
FROM pg_stat_user_tables
WHERE n_dead_tup > 0;

解决方案：调整 autovacuum_vacuum_scale_factor 或手动触发 VACUUM。

分析物理存储布局

查看行的物理地址和版本链：

SELECT ctid, xmin, xmax, * FROM my_table WHERE id = 123;