1. 当我们说"页结构"时，到底在说什么？

想象你面前有个抽屉柜，每个抽屉都塞满了杂物。PostgreSQL存储数据的方式与这个场景十分相似——页（Page）就是它的"抽屉"，每个标准抽屉的容量固定为8KB（可通过编译时参数修改）。这些抽屉内部的结构非常讲究：

-- 查看当前数据库的块大小（单位：字节）
SELECT current_setting('block_size')::int;  --> 通常返回8192（即8KB）

打开这个抽屉，你会发现它被划分为四个核心区域：

  • 页头（Page Header）：记录事务ID、校验和等元数据（占24字节）
  • 行指针（Line Pointer）：记录每条数据的位置索引（每条占4字节）
  • 行数据（Item Data）：实际存储表数据的区域
  • 空闲空间（Free Space）：留给未来数据更新的缓冲区域

假设我们有个用户表存储了200条用户记录：

CREATE TABLE users (
    id SERIAL PRIMARY KEY,
    name VARCHAR(64),
    email VARCHAR(128) UNIQUE,
    created_at TIMESTAMP DEFAULT NOW()
) WITH (FILLFACTOR = 90); -- 抽屉预留10%空位

当不断插入新用户时，抽屉的空闲空间会逐渐耗尽。这时候就像抽屉塞得太满无法放入新物品，系统不得不执行页分裂——把原页的部分数据迁移到新页，这个过程会产生页面碎片和I/O开销。

2. 填充因子：你的数据存储规划师

**填充因子（Fillfactor）**就像是在抽屉里预先留出空位的工作台。它的数值代表页空间的初始填充比例，以下是具体参数对应关系：

  • FILLFACTOR = 100：不留任何空位（默认值）
  • FILLFACTOR = 70：预留30%空闲空间
  • FILLFACTOR = 0：等同于100%（特殊保留值）

来看一个订单表的经典用例：

-- 创建高频更新的订单表（技术栈：PostgreSQL 16）
CREATE TABLE orders (
    order_id BIGSERIAL PRIMARY KEY,
    user_id INT NOT NULL,
    amount NUMERIC(10,2),
    status VARCHAR(20) CHECK(status IN ('pending', 'processing', 'shipped')),
    updated_at TIMESTAMP DEFAULT NOW()
) WITH (FILLFACTOR = 80); -- 预留20%更新空间

-- 插入压力测试数据
INSERT INTO orders (user_id, amount, status)
SELECT (random()*1000)::int, 
       (random()*1000 + 50)::numeric(10,2),
       CASE WHEN random() < 0.3 THEN 'pending'
            WHEN random() < 0.6 THEN 'processing'
            ELSE 'shipped' END
FROM generate_series(1, 100000);

当订单状态持续更新时（比如从pending变为processing），合适的填充因子可以：

  1. 延迟页分裂发生的时间
  2. 保持相关数据在物理存储上的连续性
  3. 减少更新操作导致的随机写入

3. 页分裂全过程实操演示

启用页面检查扩展观察数据分布：

-- 安装页分析工具
CREATE EXTENSION pageinspect;

-- 查看订单表第一页的数据分布
SELECT lp, lp_off, lp_len, t_xmin, t_xmax
FROM heap_page_items(get_raw_page('orders', 0))
ORDER BY lp;

假设我们执行批量更新：

-- 模拟高频更新操作
UPDATE orders 
SET status = 'shipped',
    updated_at = NOW()
WHERE status = 'processing'
RETURNING order_id;

更新前后对比使用pageinspect观察页内数据变化：

-- 更新前查询页内空闲空间
SELECT pg_freespace('orders'::regclass); -- 查看整体空闲率

-- 更新后再次检查特定页
SELECT * 
FROM heap_page_items(get_raw_page('orders', 1)) 
WHERE t_xmax <> 0; -- 查找发生变更的行

当空闲空间不足时，你会看到：

  1. 旧的元组被标记为删除（t_xmax被赋值）
  2. 新版本数据被写入同一页的空闲区域
  3. 当无法找到足够空间时触发页分裂

4. 配置填充因子的黄金法则

4.1 最佳参数设置策略

  • OLTP型表（写密集型）：70-90
  • 混合读写表：85-95
  • 静态数据表：保持默认100
  • GIN索引：建议设置为70
  • GiST索引：建议设置为90

调整现有表的配置方法：

-- 修改用户表的填充因子
ALTER TABLE users SET (FILLFACTOR = 85);

-- 重建索引应用新设置
REINDEX INDEX users_pkey;

-- 验证设置是否生效
SELECT reloptions 
FROM pg_class 
WHERE relname = 'users'; --> 应返回{FILLFACTOR=85}

4.2 必须配合使用的关联技术

结合**HOT（Heap Only Tuple）**更新机制：

-- 确保表的填充因子设置合适
ALTER TABLE orders SET (fillfactor = 80);

-- 添加必要的覆盖索引
CREATE INDEX ON orders (status) INCLUDE (updated_at);

-- 定期执行VACUUM维护
VACUUM ANALYZE orders;

通过EXPLAIN验证更新计划：

EXPLAIN (ANALYZE, BUFFERS)
UPDATE orders SET status = 'processing' WHERE order_id = 500;

关注执行计划中的：

  • Heap Fetches：HOT更新的次数
  • Buffers: shared hit：缓存命中情况

5. 典型的应用场景分析

5.1 该用填充因子的情况

  1. 频繁更新的状态字段

    -- 用户会话表（每分钟更新心跳时间）
CREATE TABLE user_sessions (
    session_id UUID PRIMARY KEY,
    user_id INT NOT NULL,
    last_active TIMESTAMP,
    data JSONB
) WITH (FILLFACTOR = 75);

  2. 数组或JSONB字段的局部更新

    -- 商品属性表（频繁修改特征标签）
CREATE TABLE products (
    sku VARCHAR(20) PRIMARY KEY,
    tags VARCHAR[],
    attributes JSONB
) WITH (FILLFACTOR = 80);

5.2 不推荐使用的场景

  1. 只读的历史数据表

    -- 年度销售归档表
CREATE TABLE sales_archive_2023 (
    LIKE sales INCLUDING ALL
) WITH (FILLFACTOR = 100);

  2. 全表扫描为主的报表查询

    -- 数据分析宽表
CREATE TABLE report_wide_table (
    date DATE,
    metrics JSONB
) WITH (FILLFACTOR = 100);

6. 技术方案的优劣对比

优势：

  • 减少约30-50%的页分裂操作（根据实际负载）
  • 提升UPDATE/DELETE操作的吞吐量
  • 降低索引树的维护成本

劣势：

  • 存储空间消耗增加约15-20%
  • 全表扫描性能可能下降5-10%
  • 需要额外的维护成本（重建索引）

7. 必须知道的注意事项

  1. 级联效应问题
    主表填充因子调整后，相关索引需要重建：

    -- 错误做法：仅修改表参数
ALTER TABLE orders SET (FILLFACTOR = 80);

-- 正确流程：重建所有相关索引
REINDEX TABLE orders;

  2. 版本差异
    PostgreSQL 12之后支持索引级别的填充因子：

    -- 创建特定填充因子的索引
CREATE INDEX orders_status_idx 
ON orders(status) 
WITH (FILLFACTOR = 70);

  3. 监控手段
    使用pgstattuple扩展分析表状态：

    SELECT * 
FROM pgstattuple('orders') 
WHERE free_percent > 20; -- 检查空间浪费

8. 总结思考

通过对页结构和填充因子的深入调优，我们可以在这些场景获得显著提升：

  • 当每小时更新次数超过500次的表
  • JSONB字段存在局部更新的情况
  • 使用UUID作为主键的时序数据

最终的优化效果就像给数据库引擎加装了缓冲气垫——虽然需要牺牲部分存储空间，但换来了更平稳的运行状态。建议配合使用pg_stat_user_tables监控页分裂次数：

SELECT schemaname,
       relname,
       n_tup_upd,
       n_tup_hot_upd
FROM pg_stat_user_tables
WHERE n_tup_upd > 1000; -- 查找高频更新表

记住，没有放之四海而皆准的参数配置。通过pgbench压测不同参数组合：

pgbench -c 10 -j 2 -T 300 -f update_test.sql

结合业务负载特征不断优化，才能让填充因子真正发挥其缓冲作用。