PostgreSQL on 吾爱主机

PostgreSQL Autovacuum：触发机制、表膨胀与参数调优

Sat, 01 Aug 2026 00:00:00 +0800

PostgreSQL 使用 MVCC 让读写尽量互不阻塞，但它也带来一个容易被忽略的代价：UPDATE 和 DELETE 不会立刻从物理文件中移除旧版本。旧元组只有在不再可能被任何事务看到后，才能由 VACUUM 清理并把空间标记为可复用。

Autovacuum 不是“可有可无的后台整理器”，而是 PostgreSQL 稳定运行的基础设施。它同时承担回收死元组、更新优化器统计信息、维护可见性映射以及防止事务 ID 回卷等工作。本文从触发公式、监控 SQL和调优方法三个角度，解释如何避免表膨胀与查询性能逐步恶化。

一、为什么会产生死元组

假设执行：

UPDATE orders SET status = 'paid' WHERE id = 1001;

PostgreSQL 通常不会在原位置覆盖旧行，而是创建新版本，并让旧版本在满足可见性条件前继续存在。这样，较早开始的事务仍可读取它应该看到的快照。

当旧版本不再对任何事务可见时，它就成为 dead tuple。若清理速度长期低于写入速度，会出现：

表和索引占用空间持续增加；
顺序扫描需要读取更多数据页；
缓存命中效率下降，磁盘 I/O 增加；
优化器统计信息过旧，可能选择错误执行计划；
维护操作耗时越来越长。

需要注意：普通 VACUUM 主要把空间交还给表内部复用，通常不会立即缩小操作系统看到的文件。VACUUM FULL 会重写整张表并归还空间，但需要额外磁盘空间和排他锁，因此不适合作为日常维护手段。

二、Autovacuum 的触发公式

对更新和删除产生的死元组，触发阈值可近似理解为：

vacuum 触发数 = autovacuum_vacuum_threshold
 + autovacuum_vacuum_scale_factor × 表估算行数

PostgreSQL 18 的默认值为：

autovacuum_vacuum_threshold = 50
autovacuum_vacuum_scale_factor = 0.2

一张估算为 1000 万行的表，默认需要约 200 万个更新或删除元组才触发一次 vacuum：

50 + 0.2 × 10,000,000 = 2,000,050

这对小表通常没问题，但对高频更新的大表可能过于宽松。分析统计信息的触发方式类似：

analyze 触发数 = autovacuum_analyze_threshold
 + autovacuum_analyze_scale_factor × 表估算行数

默认 autovacuum_analyze_threshold 为 50，autovacuum_analyze_scale_factor 为 0.1。

三、先监控，再调参数

1. 找出死元组较多的表

SELECT
 schemaname,
 relname,
 n_live_tup,
 n_dead_tup,
 round(
 100.0 * n_dead_tup / NULLIF(n_live_tup + n_dead_tup, 0),
 2
 ) AS dead_pct,
 last_autovacuum,
 last_autoanalyze,
 autovacuum_count,
 autoanalyze_count
FROM pg_stat_user_tables
ORDER BY n_dead_tup DESC
LIMIT 20;

不要只盯着 dead_pct：百万行大表的 5% 可能已经很多，而几十行小表的 50% 通常影响有限。应同时观察绝对数量、增长速度、表尺寸和业务延迟。

2. 查看表与索引大小

SELECT
 n.nspname AS schema_name,
 c.relname AS table_name,
 pg_size_pretty(pg_table_size(c.oid)) AS table_size,
 pg_size_pretty(pg_indexes_size(c.oid)) AS indexes_size,
 pg_size_pretty(pg_total_relation_size(c.oid)) AS total_size
FROM pg_class c
JOIN pg_namespace n ON n.oid = c.relnamespace
WHERE c.relkind = 'r'
 AND n.nspname NOT IN ('pg_catalog', 'information_schema')
ORDER BY pg_total_relation_size(c.oid) DESC
LIMIT 20;

pg_stat_user_tables 中的元组数是统计估算，不是严格实时计数。累计统计可能有短暂延迟，而且默认在同一事务中读取时会缓存到事务结束，因此排障时应避免在长事务里反复查询后误判数据没有变化。

3. 检查 Autovacuum 是否正在工作

SELECT
 pid,
 datname,
 relid::regclass AS table_name,
 phase,
 heap_blks_total,
 heap_blks_scanned,
 heap_blks_vacuumed,
 index_vacuum_count
FROM pg_stat_progress_vacuum;

同时检查全局配置：

SHOW autovacuum;
SHOW track_counts;
SHOW autovacuum_max_workers;
SHOW autovacuum_naptime;
SHOW autovacuum_vacuum_cost_delay;
SHOW autovacuum_vacuum_cost_limit;

四、针对热点大表做局部调优

相比一开始就修改全局配置，更稳妥的方式是为写入最频繁的表设置存储参数：

ALTER TABLE orders SET (
 autovacuum_vacuum_scale_factor = 0.02,
 autovacuum_vacuum_threshold = 1000,
 autovacuum_analyze_scale_factor = 0.02,
 autovacuum_analyze_threshold = 1000
);

若 orders 有 1000 万行，新的 vacuum 触发值约为：

1000 + 0.02 × 10,000,000 = 201,000

这比默认约 200 万行更及时，同时不会让所有表都采用同样激进的策略。调整后至少持续观察一个完整业务周期：

n_dead_tup 是否形成可控波动而非持续上升；
autovacuum 的执行次数与单次持续时间；
数据盘 IOPS、吞吐和延迟；
SQL 的 P95/P99 延迟；
表和索引尺寸是否趋于稳定。

五、为什么“调低阈值”仍可能无效

1. 长事务阻止清理

只要某个老快照仍可能看见旧版本，VACUUM 就不能安全移除它。可先排查长时间未结束的事务：

SELECT
 pid,
 usename,
 state,
 xact_start,
 now() - xact_start AS xact_age,
 wait_event_type,
 wait_event,
 left(query, 120) AS query
FROM pg_stat_activity
WHERE xact_start IS NOT NULL
ORDER BY xact_start;

应用连接池中的 idle in transaction、未提交的批处理、长期保持的报表事务，都是常见根因。此时继续降低 scale factor，只会让 vacuum 更频繁地尝试，却未必能回收空间。

2. 清理能力跟不上写入速度

Autovacuum 使用基于成本的延迟机制来降低后台维护对前台业务的 I/O 冲击。如果多张大表同时高频更新，worker 数量、成本限额或磁盘能力可能成为瓶颈。

调优顺序建议是：

先解决长事务和异常写入；
针对热点表降低触发阈值；
确认磁盘有余量后，再评估 worker 数量和成本参数；
每次只改一组参数，并保留前后监控数据。

不要只为“让 vacuum 尽快结束”就无限提高成本限额，否则维护 I/O 可能直接影响在线查询。

3. 误把内部可复用空间当成故障

普通 VACUUM 后文件不缩小，并不表示它没有工作。若表仍会持续写入，保留并复用这些空闲空间往往比频繁执行 VACUUM FULL 更合理。

只有在一次性大规模删除、确认未来不会很快重新增长，并且能够安排锁表维护窗口时，才考虑 VACUUM FULL、CLUSTER 或其他表重写方案。执行前必须预留接近表及索引重建所需的额外空间。

六、生产调优清单

保持 autovacuum 开启，不要把关闭它当成性能优化。
用 pg_stat_user_tables 建立死元组数量、比例和清理时间的趋势图。
优先为热点大表设置表级参数，避免粗暴修改全局阈值。
同时监控磁盘 I/O 和业务延迟，防止维护任务挤压前台负载。
排查长事务、复制槽和其他可能维持旧快照的因素。
将普通 VACUUM 作为日常机制，把表重写当作有维护窗口的例外操作。
定期检查事务 ID 年龄，不能只关注磁盘膨胀。

总结

Autovacuum 的本质不是“定时清垃圾”，而是根据表的变更规模动态触发的一组维护任务。真正有效的优化，不是简单把参数调得更激进，而是让触发频率、清理吞吐和业务写入速度达到平衡。

面对表膨胀时，应先回答三个问题：死元组为什么持续产生、为什么未被及时清理、普通 VACUUM 回收的空间是否已经被业务复用。把这些问题与长事务、I/O 能力和表级阈值结合起来分析，通常比直接执行 VACUUM FULL 更安全，也更接近根因。

参考资料

PostgreSQL WAL、检查点与崩溃恢复：原理、参数与工程实践

Fri, 31 Jul 2026 00:00:00 +0800

生产环境里，数据库“提交成功”并不等于数据页已经刷到表文件。PostgreSQL 用 Write-Ahead Logging（WAL，预写日志） 把变更先顺序写到日志，再异步回写堆/索引页；一旦进程或主机崩溃，就从最近检查点（checkpoint）开始 REDO 前滚，把还没落盘的变更重放回来。理解 WAL 与检查点，才能在“提交延迟、恢复时间、磁盘占用”之间做正确取舍，而不是盲目把 fsync 关掉。

问题背景：为什么不能每次提交都刷数据页？

一次事务可能修改很多表页。如果每次 COMMIT 都把相关数据页 fsync 到磁盘：

随机写成本高：小事务会在不同数据文件之间来回寻道。
吞吐难扩展：并发提交会互相争抢刷脏页。
恢复语义更复杂：缺少统一的“已持久化边界”。

WAL 的核心规则（官方表述）：对数据文件的修改，必须在描述该修改的 WAL 记录刷到永久存储之后才能写入数据页。遵循这条规则后，提交时只需保证相关 WAL 已落盘，崩溃时再用日志重做（roll-forward / REDO）尚未写入数据页的变更。

这带来两个工程收益：

提交路径偏顺序写：同步成本主要在 WAL 文件，而不是整页随机写。
支持在线备份与 PITR：归档 WAL + 基准备份，可回放到任意覆盖时间点。

核心原理：LSN、段文件、检查点与 REDO

1. LSN：日志里的“字节尺”

每条 WAL 记录写入后，插入位置用 Log Sequence Number（LSN） 描述，本质上是 WAL 中单调递增的字节偏移。PostgreSQL 用 pg_lsn 类型表示它，可用于比较两点之间产生了多少 WAL、衡量复制与恢复进度。

常用函数：

-- 当前 WAL 写位置
SELECT pg_current_wal_lsn();

-- 计算两个 LSN 之间的字节差（备份/复制场景常用）
SELECT pg_wal_lsn_diff(pg_current_wal_lsn(), '0/0');

2. 段文件布局：`pg_wal` 里的 16MB 段

WAL 默认存放在数据目录下的 pg_wal/（历史版本曾叫 pg_xlog）。段文件通常 每段 16MB（initdb --wal-segsize 可改），段内再按页划分（常见 8kB）。文件名是递增编号，例如从 000000010000000000000001 起。

运维提示：

WAL 磁盘与主数据盘分离，有助于把顺序写与随机写解耦（可在停库后迁移 pg_wal 并用符号链接指回原路径）。
段文件在检查点之后、确认不再需要时会被 回收重命名 或删除；归档模式下必须先归档再回收。

3. 检查点：恢复的“安全锚点”

检查点是 WAL 序列中的一个保证点：该点之前的堆/索引变更，都已反映到数据文件并刷盘。检查点过程会：

把脏数据页写回磁盘；
在 WAL 中写入特殊的 checkpoint 记录；
把检查点位置写入 pg_control。

崩溃恢复时，服务器：

读 pg_control 找到最新检查点；
定位 checkpoint 记录中的 redo 起点；
从该 LSN 向前扫描 WAL 做 REDO。

因此：检查点越频繁，崩溃后需要重放的 WAL 通常越少，恢复更快；但刷脏页更勤，运行期 I/O 更重。

默认自动触发条件（二者先到为准）：

参数	含义	默认（官方文档）
`checkpoint_timeout`	两次自动检查点的最长时间间隔	5 分钟
`max_wal_size`	自动检查点期间 WAL 增长的软上限	1 GB
`checkpoint_completion_target`	检查点 I/O 在间隔内的目标完成比例	0.9
`min_wal_size`	低于该占用时优先回收复用段，而不是删除	80 MB

CHECKPOINT SQL 可强制立即检查点，但文档明确：不适合作为常规业务操作，一般留给维护窗口或排障。

4. 全页写（Full Page Writes）与页撕裂

默认 full_page_writes = on：检查点之后，某个数据页 第一次被修改 时，会把 整页内容 记入 WAL（FPI，full page image）。目的是防止崩溃时页只写了一半（torn page），仅靠“增量修改记录”无法正确还原。

代价是：检查点刚结束后的一段时间内 WAL 量会冲高。高负载系统常通过合理调大 max_wal_size / checkpoint_timeout，避免检查点过于密集导致 FPI 风暴。

提交耐久性：`synchronous_commit` 与 `fsync`

这是最容易踩坑的一组旋钮，必须分清 丢最近事务 与 数据库损坏 的差别。

`synchronous_commit`（可会话级调整）

控制：在向客户端返回“成功”前，WAL 需要处理到什么程度。合法值包括：

remote_apply、on（默认）、remote_write、local、off。

关键语义：

非 off 的本地行为：等待 本地 WAL 刷盘。
off（异步提交）：逻辑提交完成后即可返回，不等待 WAL 落盘；崩溃可能丢失最近若干已“成功”的事务。
官方强调：异步提交的风险是 数据丢失，不是数据损坏。恢复仍会重放到最后已刷盘的 WAL，库状态自洽，只是像最近事务被干净回滚一样。

典型用法：

-- 会话级：日志/埋点等可接受极短窗口丢失
SET synchronous_commit = off;

INSERT INTO event_log(payload) VALUES ('...');
-- 默认仍是 on；按事务开始时的参数值决定该事务提交模式

银行出钞、扣款等“客户端会据此做外部动作”的场景，不要关同步提交。

`fsync`（集群级，危险）

fsync = on 时，PostgreSQL 通过 fsync() 或等价方法（见 wal_sync_method）尽量把更新真正写到磁盘，保证 OS/硬件崩溃后仍可恢复到一致状态。

关掉 fsync 可能换来吞吐，但在掉电/系统崩溃时可能导致 不可恢复损坏。文档只建议在可整体重建的场景（初始装载、用完即丢的批处理库、只读克隆等）临时关闭。

工程对照：

设置	主要风险	适用
`synchronous_commit=off`	丢最近事务，库仍一致	可丢失的短事务
`fsync=off`	可能损坏，需重建	几乎仅限可重建环境
默认两者开启	提交稍慢，耐久性强	绝大多数生产

可复现观测实验（实验室）

下面命令假设你有一个可写的测试实例。目标是把“看不见的 WAL 机制”变成可观察指标。

1）看当前 WAL 与检查点统计

SHOW wal_level;
SHOW fsync;
SHOW synchronous_commit;
SHOW checkpoint_timeout;
SHOW max_wal_size;
SHOW min_wal_size;
SHOW full_page_writes;
SHOW checkpoint_completion_target;

SELECT pg_current_wal_lsn() AS current_lsn;

-- 新版本检查点统计在 pg_stat_checkpointer
SELECT num_timed, num_requested, num_done,
 write_time, sync_time, buffers_written
FROM pg_stat_checkpointer;

-- WAL 生成量与 FPI
SELECT wal_records, wal_fpi, wal_bytes, wal_buffers_full
FROM pg_stat_wal;

说明：

num_timed / num_requested 会计入完成与跳过；num_done 只计真正完成的检查点。
空闲实例可能因“自上次检查点以来没有 WAL”而跳过定时检查点。

2）制造 WAL 并观察 LSN 前进

在 psql 中：

CREATE TABLE IF NOT EXISTS wal_lab(
 id bigserial PRIMARY KEY,
 payload text
);

-- 记录写入前 LSN（psql 变量）
SELECT pg_current_wal_lsn() AS before_lsn \gset

INSERT INTO wal_lab(payload)
SELECT repeat('x', 200)
FROM generate_series(1, 5000);

SELECT pg_current_wal_lsn() AS after_lsn,
 pg_wal_lsn_diff(pg_current_wal_lsn(), :'before_lsn') AS wal_bytes;

pg_wal_lsn_diff 返回两个 LSN 之间的字节差，便于量化一次批量写入产生了多少 WAL。若不用 \gset，可先手工抄下 before_lsn 再代入比较。

3）对比同步/异步提交延迟（概念实验）

\timing on

BEGIN;
SET LOCAL synchronous_commit = on;
INSERT INTO wal_lab(payload) VALUES ('sync');
COMMIT;

BEGIN;
SET LOCAL synchronous_commit = off;
INSERT INTO wal_lab(payload) VALUES ('async');
COMMIT;

在高并发小事务压测下，异步提交通常降低提交等待；但要清楚这是 用丢失窗口换延迟，不是免费午餐。

4）强制检查点（仅实验）

CHECKPOINT;
SELECT num_done, write_time, sync_time, buffers_written
FROM pg_stat_checkpointer;

观察 write_time / sync_time 与 buffers_written 的变化，理解检查点 I/O 的代价。

工程调参与排错清单

恢复时间 vs 运行期 I/O

缩短崩溃恢复：减小 checkpoint_timeout / max_wal_size → 检查点更勤 → REDO 更少。
减轻检查点尖峰：增大二者，并把 checkpoint_completion_target 维持在接近 0.9，让刷脏页摊到整个间隔。
不要用检查点频率去“保证归档频率”：若关心归档 RPO，应调 archive_timeout，而不是把检查点拧得很紧。

WAL 目录膨胀

常见原因：

归档命令失败，段无法回收；
复制槽（replication slot）落后，强制保留旧段；
wal_keep_size / 相关保留设置过大；
批量导入、索引重建产生大量 WAL。

排查思路：

-- 归档相关（若启用）
SHOW archive_mode;
SHOW archive_command;
SHOW archive_timeout;

-- 当前是否在恢复（备库）
SELECT pg_is_in_recovery();

同时检查 pg_wal 磁盘占用、复制槽延迟与归档日志报错。

`wal_level` 选型

级别	大致用途
`minimal`	仅崩溃恢复所需信息，体积最小；不足以 PITR/流复制
`replica`（默认）	支持归档与物理复制、备库只读查询
`logical`	在 replica 基础上增加逻辑解码所需信息

生产若要做流复制或连续归档，不要用 minimal；文档还指出：max_wal_senders 非 0 时甚至不能以 minimal 启动。

硬件与虚假“写成功”

WAL 要求日志先于数据页持久化。若磁盘/控制器 谎报写完成（只进缓存未真正落盘），掉电仍可能造成不可恢复损坏。务必确认 WAL 所在存储关闭了危险写缓存，或有电池备份写缓存（BBU）。

常见坑对照表

现象	可能原因	处理方向
提交延迟高、小事务 TPS 低	每次提交都在等 WAL fsync	评估 `synchronous_commit=off`（可丢）或提升 WAL 盘延迟；关注 group commit
检查点期间延迟尖刺	脏页集中刷写	调大 `max_wal_size`/`checkpoint_timeout`，保持 `checkpoint_completion_target≈0.9`
崩溃恢复很久	检查点过稀，REDO 区间过长	适度降低 `max_wal_size` 或 `checkpoint_timeout`
`pg_wal` 撑满磁盘	归档失败 / 复制槽落后	修归档、清理无用槽、扩容并监控
关 `fsync` “更快”	用损坏风险换吞吐	生产禁止；可重建场景才临时关闭
异步提交后“丢单”	崩溃窗口内事务未刷盘	业务上接受丢失，或关键路径保持 `on`
检查点后 WAL 暴涨	FPI（`full_page_writes`）	避免检查点过密；观察 `pg_stat_wal.wal_fpi`

总结

WAL 先于数据页：提交持久化的关键路径是刷 WAL，而不是立刻刷所有脏表页。
检查点定义 REDO 起点：checkpoint_timeout 与 max_wal_size 共同决定自动检查点节奏，直接影响崩溃恢复时间与运行期 I/O。
synchronous_commit=off ≠ fsync=off：前者可能丢最近事务但保持一致；后者可能损坏。
用 LSN 与统计视图观测：pg_current_wal_lsn、pg_stat_checkpointer、pg_stat_wal 把机制落到指标。
调参要绑定目标：RTO（恢复时间）、提交延迟、磁盘占用、复制/归档 RPO，不要只抄一组“神秘最优参数”。

把这些机制吃透后，再去谈高可用、PITR、逻辑复制，才会知道每条配置背后买的是什么、卖的是什么。

参考资料

PostgreSQL B-tree 索引：结构、扫描方式与工程实践

Fri, 24 Jul 2026 00:00:00 +0800

线上 SQL 变慢时，第一反应往往是“加个索引”。但在 PostgreSQL 里，索引不是“有就快”的开关：默认的 B-tree 适合哪些谓词？多列索引为什么“左边优先”？为什么 EXPLAIN 里会出现 Index Scan、Bitmap Heap Scan 或 Index Only Scan？部分索引、INCLUDE 覆盖列、CREATE INDEX CONCURRENTLY 又分别解决什么工程问题？

本文基于 PostgreSQL 官方文档（当前文档站对应 PostgreSQL 18 手册章节），从机制讲到可复现实验与排错清单，帮助你把索引用在真正该用的地方。

问题背景：没有索引时，数据库在做什么

官方索引导论用了一个很直观的例子：表 test1(id, content) 上频繁执行：

SELECT content FROM test1 WHERE id = constant;

如果没有预先准备，系统只能 逐行扫描整表 找匹配行；行数很大而命中很少时，这显然低效。若在 id 上维护索引，定位匹配行可以走更高效的路径（例如在搜索树中只走几层），而不必通读整本书式的堆表。

关键工程含义：

索引要提前“预见”查询会怎样查找数据——这是 DBA/开发者的职责，而不是数据库自动替你猜对所有场景。
索引创建后会随表的增删改自动维护，但也会带来 写放大与存储开销。
规划器是否选用索引，依赖统计信息；因此要定期 ANALYZE，并学会用 EXPLAIN 验证真实计划。

核心原理：为什么日常几乎都是 B-tree

PostgreSQL 提供多种索引访问方法：B-tree、Hash、GiST、SP-GiST、GIN、BRIN，以及扩展如 bloom。
CREATE INDEX 默认创建 B-tree，因为它覆盖了最常见的相等与范围查询场景。其它类型需要显式 USING method，例如：

CREATE INDEX name ON table USING HASH (column);

B-tree 能加速哪些谓词

官方说明：B-tree 可处理 可排序数据 上的相等与范围查询。规划器会在索引列参与下列比较时考虑使用 B-tree：

运算符 / 形态	说明
`<` `<=` `=` `>=` `>`	基本比较
`BETWEEN` / `IN`	可视为上述比较的组合
`IS NULL` / `IS NOT NULL`	也可用于 B-tree
`LIKE` / `~`	仅当模式为常量且锚定在字符串开头，如 `col LIKE 'foo%'`、`col ~ '^foo'`；`'%bar'` 这类前后缀/中间匹配不行

补充：

非 C locale 时，模式匹配类查询可能需要特殊 operator class 才能用索引（见手册“Operator Classes and Operator Families”相关章节）。
ILIKE / ~* 更受限：模式通常需要以“不受大小写转换影响的字符”开头。
Hash 索引 只存 32-bit 哈希码，因此 只能处理简单相等比较，不能替代 B-tree 的范围与排序能力。

只有 B-tree 能“带着顺序”吐行

索引除了找行，还可能直接按指定顺序交付结果，从而避免额外排序。官方明确：在当前支持的索引类型中，只有 B-tree 能产生有序输出；其它类型返回匹配行的顺序是未指定、实现相关的。

默认 B-tree 条目按 升序、NULLS LAST 存储（相等时用表 TID 作决胜列）。因此：

正向扫描满足 ORDER BY x（即 ASC NULLS LAST）
反向扫描可满足 ORDER BY x DESC（对应 DESC NULLS FIRST 等组合规则）

工程上特别有价值的形态是 ORDER BY ... LIMIT n：显式排序往往要处理全部候选才能取前 n 行；若有匹配的 B-tree，可直接取前 n 行，无需扫完剩余数据。

唯一性约束如何落地

目前只有 B-tree 可声明为 unique。
默认情况下，唯一列中的 多个 NULL 不视为相等（允许多个 NULL）；NULLS NOT DISTINCT 会把 NULL 当相等处理。
定义 PRIMARY KEY / UNIQUE 约束时，PostgreSQL 会自动创建 对应唯一索引，无需再手写一份重复索引。

扫描方式：同一条 SQL，三种常见“走路方式”

PostgreSQL 的索引是 二级索引（secondary index）：索引与堆表（heap）分开存储。普通索引扫描通常既读索引，又回表读堆；匹配的索引项可能相邻，但对应堆行可能散落各处，带来随机 I/O。

1）Index Scan：点查 / 高选择性范围

适合“索引快速锁定少量行，再回表取完整行”的路径。EXPLAIN 中常见 Index Scan using ...。

2）Bitmap Index Scan + Bitmap Heap Scan：中等选择性或组合条件

当需要组合多个索引、或单次索引扫描无法直接表达某些 OR/AND 形态时，系统可：

扫描一个或多个索引，在内存中生成 bitmap（标记可能命中的堆位置）
对 bitmap 做 AND / OR
再按 物理顺序 访问堆表（Bitmap Heap Scan）

官方指出：按物理序访问会 丢失原索引顺序，因此后续若需要排序，可能再加 Sort。这也解释了：bitmap 路径擅长降低随机 I/O，但不一定能顺便满足 ORDER BY。

3）Index Only Scan：尽量不回表

Index-only scan 的目标是 只靠索引回答查询。官方给出两个基本前提：

索引类型支持 index-only scan：B-tree 始终支持；GiST/SP-GiST 仅部分 operator class；GIN 等通常不支持（索引项往往只存原值的一部分）。
查询只引用索引中存有的列。例如索引在 (x, y) 上：
- 可用：SELECT x, y FROM tab WHERE x = 'key';
- 不可用（还要读 z）：SELECT x, z FROM tab WHERE x = 'key';

即便列都在索引里，PostgreSQL 仍要做 MVCC 可见性 判断。可见性信息不在索引项里，而在堆中；因此引入 visibility map（可见性映射）：

若堆页对应 all-visible 位已设置，可认为行对当前/未来事务可见，无需再访问堆元组
若未设置，仍需回表检查可见性——此时相对普通 Index Scan 的收益会明显下降

因此：Index Only Scan “物理上可能”，但 只有当表中相当比例堆页的 all-visible 位有效时 才更划算。对“大量行很少变化”的表，这类扫描非常实用；写很频繁、可见性图难以保持的表，收益会打折。

覆盖索引与 `INCLUDE`

为了让高频查询更容易走 index-only，可以做 covering index（覆盖索引）：让索引包含查询需要返回/过滤的列。PostgreSQL 允许用 INCLUDE 添加 非键（non-key）列：

非键列不能用于索引扫描的查找条件，也不参与唯一/排他约束判定
但 index-only scan 可直接从索引叶子返回这些列，无需回表
INCLUDE 列会增大索引、复制数据；宽列要谨慎
带 non-key 列的 B-tree 不会使用 deduplication
表达式不能作为 INCLUDE 列（因为无法用于 index-only scan）
当前 B-tree / GiST / SP-GiST 支持该特性；叶子存 INCLUDE 值，上层导航项不包含它们

-- 键列用于查找，INCLUDE 列服务于覆盖返回
CREATE INDEX orders_user_created_cover
 ON orders (user_id, created_at)
 INCLUDE (status, amount);

多列索引、部分索引：选型比“多建几个”更重要

多列 B-tree：最左前缀与效率

索引最多 32 列（含 INCLUDE；编译期可改 pg_config_manual.h）。
多键列目前由 B-tree、GiST、GIN、BRIN 等支持（与能否 INCLUDE 是两件独立的事）。
多列 B-tree 可用于涉及任意列子集的条件，但 在前导（最左）列上有约束时最高效。
精确规则（官方表述）：对前导列的 相等约束，加上第一个没有相等约束的列上的 不等式约束，总是用于限制扫描的索引区间；更右侧列上的条件仍会在索引内检查（可减少回表），但不一定缩小扫描区间。
新版本还有 skip scan 优化：在合适基数下，可对缺少常规相等约束的中间列做内部动态相等约束，减少读取区间——但这是优化，不是让你随意打乱“左前缀”设计习惯。

经验对照：

查询形态	更合适的索引直觉
总是 `WHERE a = ? AND b = ?`	`(a, b)` 复合索引
有时只有 `a`，有时只有 `b`，有时两者	可能两个单列 + 让规划器组合；或评估 skip scan / 复合
`ORDER BY a, b LIMIT n`	与排序方向一致的 `(a, b)` B-tree
只查“活跃订单”等小子集	部分索引往往比全表索引更划算

部分索引：只索引“值得索引”的子集

部分索引建立在表的一个子集上，子集由谓词（WHERE）定义，索引 只包含满足谓词的行。

官方给出的核心动机：

避免给常见值建索引：若某值占比很高，查它本来也未必走索引，放进索引只会白白增大体积、拖慢写路径。
缩小索引 → 命中索引的查询更快，且很多更新不必维护该索引。

典型场景：访问日志中组织内网 IP 占比极高，但排查更关心外部 IP：

CREATE INDEX access_log_client_ip_ix
 ON access_log (client_ip)
 WHERE NOT (
 client_ip > inet '192.168.100.0'
 AND client_ip < inet '192.168.100.255'
 );

只有查询条件也落在“被索引子集”内时，规划器才能使用该部分索引；条件与谓词冲突时不会用。

可复现实验：从建表到读懂 EXPLAIN

下面用一套小实验把机制落到命令（在任意 PostgreSQL ≥ 14 环境可跑；语句本身与官方语义一致）。

-- 1) 准备数据
DROP TABLE IF EXISTS demo_orders;
CREATE TABLE demo_orders (
 id bigserial PRIMARY KEY,
 user_id int NOT NULL,
 status text NOT NULL,
 amount numeric(12,2) NOT NULL,
 created_at timestamptz NOT NULL DEFAULT now()
);

INSERT INTO demo_orders (user_id, status, amount, created_at)
SELECT
 (random()*10000)::int,
 (ARRAY['paid','pending','cancelled','paid','paid'])[1 + (random()*4)::int],
 round((random()*500)::numeric, 2),
 now() - ((random()*365)::int || ' days')::interval
FROM generate_series(1, 200000);

ANALYZE demo_orders;

-- 2) 无业务二级索引时看计划（主键本身是 B-tree 唯一索引）
EXPLAIN (ANALYZE, BUFFERS)
SELECT * FROM demo_orders WHERE user_id = 42;

-- 3) 建立常用复合索引 + 部分索引 + 覆盖索引
CREATE INDEX CONCURRENTLY demo_orders_user_created_idx
 ON demo_orders (user_id, created_at DESC);

CREATE INDEX CONCURRENTLY demo_orders_pending_idx
 ON demo_orders (created_at)
 WHERE status = 'pending';

CREATE INDEX CONCURRENTLY demo_orders_user_cover_idx
 ON demo_orders (user_id)
 INCLUDE (status, amount);

ANALYZE demo_orders;

-- 4) 对比计划节点名称
EXPLAIN (ANALYZE, BUFFERS)
SELECT id, status, amount
FROM demo_orders
WHERE user_id = 42
ORDER BY created_at DESC
LIMIT 20;

EXPLAIN (ANALYZE, BUFFERS)
SELECT id, created_at
FROM demo_orders
WHERE status = 'pending'
 AND created_at > now() - interval '7 days';

EXPLAIN (ANALYZE, BUFFERS)
SELECT user_id, status, amount
FROM demo_orders
WHERE user_id = 42;
-- 若统计与可见性合适，可能出现 Index Only Scan（依赖 INCLUDE 覆盖 + visibility map）

读计划时优先看：

节点类型：Seq Scan / Index Scan / Bitmap Index Scan + Bitmap Heap Scan / Index Only Scan
实际行数 vs 估算行数（rows）：偏差大 → 统计过期或谓词难估，先 ANALYZE，再考虑扩展统计
Buffers：命中共享缓冲还是读盘；Index Only Scan 是否仍有大量 heap fetches（可见性图不给力）
是否多了不必要的 Sort：排序方向与索引 (ASC/DESC, NULLS ...) 是否一致

生产变更：`CREATE INDEX CONCURRENTLY`

普通 CREATE INDEX 会对表加写锁：其它事务仍可读，但 INSERT/UPDATE/DELETE 会阻塞到索引建完。大表上这可能长达数小时，生产不可接受。

CREATE INDEX CONCURRENTLY 的官方要点：

构建过程 不获取会阻止并发写 的锁（允许正常 DML 继续）
代价：通常要 两次表扫描，并等待可能修改/使用该索引的相关事务结束，总工作量更大、耗时更长
过程中索引会先以 INVALID 状态进入系统目录；成功结束后才标为可用
若扫描阶段失败（死锁、唯一冲突等），命令失败但可能留下 INVALID 索引：查询会忽略它，却仍要为写维护它 → 推荐 DROP 后重试 CREATE INDEX CONCURRENTLY（或 REINDEX INDEX CONCURRENTLY）
CREATE INDEX CONCURRENTLY 不能放在事务块里；分区表并发构建有额外限制（可先对分区并发建，再非并发建分区父索引以缩短写锁定窗口）
同一表上 同时只能有一个 concurrent index build

CREATE INDEX CONCURRENTLY sales_quantity_index
 ON sales_table (quantity);

常见坑与排查清单

现象	常见原因	怎么查 / 怎么办
建了索引仍 `Seq Scan`	选择性差、统计过期、函数包住列导致无法匹配、成本模型认为全表更便宜	`EXPLAIN`；`ANALYZE`；避免 `WHERE func(col)=...`（改表达式索引）；用真实参数看计划
`LIKE '%x%'` 不走 B-tree	B-tree 需要前缀锚定模式	换 `pg_trgm` + GIN/GiST 等（另一条路线，不是默认 B-tree）
多列索引“像没用”	谓词没落在最左列，或类型/排序规则不匹配	检查前导列是否有相等/范围条件；核对 `ASC/DESC NULLS`
期望 Index Only Scan 却回表很多	查询列未覆盖；visibility map 中 all-visible 比例低	`INCLUDE` 覆盖；减少无意义更新；关注 vacuum 是否跟上
写变慢、膨胀	索引过多、宽 INCLUDE、低选择性索引	用 `pg_stat_user_indexes` 看扫描次数；删冗余；部分索引收窄
`CONCURRENTLY` 后有 `INVALID`	构建失败留下残留	`\d table` 确认；`DROP INDEX` 后重建
唯一约束“允许多个 NULL”	默认 NULL 不相等	需要业务唯一含 NULL 时用 `NULLS NOT DISTINCT`

辅助观测：

-- 索引是否被使用（需打开 stats）
SELECT schemaname, relname, indexrelname, idx_scan, idx_tup_read, idx_tup_fetch
FROM pg_stat_user_indexes
ORDER BY idx_scan ASC
LIMIT 30;

-- 无效索引排查（概念：concurrent 失败残留）
SELECT c.relname AS index_name, i.indisvalid
FROM pg_index i
JOIN pg_class c ON c.oid = i.indexrelid
WHERE NOT i.indisvalid;

工程实践建议（可直接落地）

先写清访问路径：等值 / 范围 / 排序 / 覆盖返回列 / 是否只查子集。
默认从 B-tree 开始：范围、排序、唯一约束几乎都靠它；Hash 仅在“只要相等且理解其限制”时考虑。
复合索引按过滤+排序设计列序：高频等值列靠左，范围/排序列靠右；方向与 ORDER BY 对齐。
热点子集优先部分索引：状态机里的 pending、软删除后的“有效行”、租户内活跃数据等。
高频只读投影再谈 INCLUDE：覆盖收益要压过索引变大与 dedup 失效的代价。
生产建索引用 CONCURRENTLY，并处理 INVALID 残留。
用 EXPLAIN (ANALYZE, BUFFERS) 闭环，而不是用“感觉”判断索引是否生效。

总结

PostgreSQL 索引体系的核心不是“类型清单”，而是三层决策：

访问方法：日常以 B-tree 承载相等、范围、排序与唯一性；Hash/GIN/GiST/BRIN 解决更专门的谓词与数据形态。
扫描算子：Index Scan 精确定位，Bitmap 组合与减少随机 I/O，Index Only Scan 在覆盖列 + 可见性图友好时避免回表。
工程形态：多列最左前缀、部分索引缩子集、INCLUDE 做覆盖、CONCURRENTLY 保障在线变更。

把这三层和 EXPLAIN 对上，索引才会从“玄学加速”变成可验证的性能工具。

PostgreSQL on 吾爱主机

PostgreSQL Autovacuum：触发机制、表膨胀与参数调优

一、为什么会产生死元组

二、Autovacuum 的触发公式

三、先监控，再调参数

1. 找出死元组较多的表

2. 查看表与索引大小

3. 检查 Autovacuum 是否正在工作

四、针对热点大表做局部调优

五、为什么“调低阈值”仍可能无效

1. 长事务阻止清理

2. 清理能力跟不上写入速度

3. 误把内部可复用空间当成故障

六、生产调优清单

总结

参考资料

PostgreSQL WAL、检查点与崩溃恢复：原理、参数与工程实践

问题背景：为什么不能每次提交都刷数据页？

核心原理：LSN、段文件、检查点与 REDO

1. LSN：日志里的“字节尺”

2. 段文件布局：pg_wal 里的 16MB 段

3. 检查点：恢复的“安全锚点”

4. 全页写（Full Page Writes）与页撕裂

提交耐久性：synchronous_commit 与 fsync

synchronous_commit（可会话级调整）

fsync（集群级，危险）

可复现观测实验（实验室）

1）看当前 WAL 与检查点统计

2）制造 WAL 并观察 LSN 前进

3）对比同步/异步提交延迟（概念实验）

4）强制检查点（仅实验）

工程调参与排错清单

恢复时间 vs 运行期 I/O

WAL 目录膨胀

wal_level 选型

硬件与虚假“写成功”

常见坑对照表

总结

参考资料

PostgreSQL B-tree 索引：结构、扫描方式与工程实践

问题背景：没有索引时，数据库在做什么

核心原理：为什么日常几乎都是 B-tree

B-tree 能加速哪些谓词

只有 B-tree 能“带着顺序”吐行

唯一性约束如何落地

扫描方式：同一条 SQL，三种常见“走路方式”

1）Index Scan：点查 / 高选择性范围

2）Bitmap Index Scan + Bitmap Heap Scan：中等选择性或组合条件

3）Index Only Scan：尽量不回表

覆盖索引与 INCLUDE

多列索引、部分索引：选型比“多建几个”更重要

多列 B-tree：最左前缀与效率

部分索引：只索引“值得索引”的子集

可复现实验：从建表到读懂 EXPLAIN

生产变更：CREATE INDEX CONCURRENTLY

常见坑与排查清单

工程实践建议（可直接落地）

总结

参考资料

2. 段文件布局：`pg_wal` 里的 16MB 段

提交耐久性：`synchronous_commit` 与 `fsync`

`synchronous_commit`（可会话级调整）

`fsync`（集群级，危险）

`wal_level` 选型

覆盖索引与 `INCLUDE`

生产变更：`CREATE INDEX CONCURRENTLY`