↑↓ 选择 ↵ 打开 ⌫ 改范围 完整检索页

pgsql.cc 提供对 postgresql.org 官网内容的中文翻译,由 Pigsty 团队维护。

百科 / Index AM / B-tree

B-tree

有序检索

B-tree 能对可按某种顺序排序的数据执行等值查询和范围查询。具体而言,当索引列参与使用下列运算符之一的比较时,PostgreSQL 查询规划器会考虑使用 B-tree 索引:

当前查看 PostgreSQL 18.6。

能力 · PostgreSQL 18.6

能力结论来自对应版本的文档。有条件支持取决于操作符类、索引类型或查询,不能视为普遍保证。

能力支持状态条件与证据
有序输出支持

普通的有序输出与按运算符排序是不同能力,例如按近邻距离排序。

同版本英文证据

In addition to simply finding the rows to be returned by a query, an index may be able to deliver them in a specific sorted order. This allows a query's ORDER BY specification to be honored without a separate sorting step. Of the index types currently supported by PostgreSQL , only B-tree can produce sorted output — the other index types return matching rows in an unspecified, implementation-dependent order.

PostgreSQL 18.6 · indexes-ordering

唯一键支持

这里指唯一索引,排除约束采用不同的约定。

同版本英文证据

Currently, only B-tree indexes can be declared unique.

PostgreSQL 18.6 · indexes-unique

多键列支持

多个检索键与不参与检索的 INCLUDE 附加列是不同概念。

同版本英文证据

Currently, only the B-tree, GiST, GIN, and BRIN index types support multiple-key-column indexes. Whether there can be multiple key columns is independent of whether INCLUDE columns can be added to the index. Indexes can have up to 32 columns, including INCLUDE columns. (This limit can be altered when building PostgreSQL ; see the file pg_config_manual.h .)

PostgreSQL 18.6 · indexes-multicolumn

INCLUDE 附加列支持

附加列不会成为检索键。过宽的附加数据可能超过索引元组大小限制。

同版本英文证据

Currently, the B-tree, GiST and SP-GiST index access methods support this feature. In these indexes, the values of columns listed in the INCLUDE clause are included in leaf tuples which correspond to heap tuples, but are not included in upper-level index entries used for tree navigation.

PostgreSQL 18.6 · sql-createindex

仅索引扫描支持

查询必须使用索引覆盖的值;能否避免访问堆取决于可见性映射状态。

同版本英文证据

The index type must support index-only scans. B-tree indexes always do. GiST and SP-GiST indexes support index-only scans for some operator classes but not others. Other index types have no support. The underlying requirement is that the index must physically store, or else be able to reconstruct, the original data value for each index entry. As a counterexample, GIN indexes cannot support index-only scans because each index entry typically holds only part of the original data value.

PostgreSQL 18.6 · indexes-index-only-scans

按距离排序未确定

可用性取决于所选操作符类和排序运算符。

现有来源不足以确定此项能力,不能据此判断为“不支持”。

并行索引扫描支持

多个进程协作扫描同一索引,不同于并行位图堆扫描,也不同于 Parallel Append 下各自独立的串行扫描。

同版本英文证据

In a parallel index scan or parallel index-only scan , the cooperating processes take turns reading data from the index. Currently, parallel index scans are supported only for btree indexes. Each process will claim a single index block and will scan and return all tuples referenced by that block; other processes can at the same time be returning tuples from a different index block. The results of a parallel btree scan are returned in sorted order within each worker process.

PostgreSQL 18.6 · parallel-plans

并行构建索引支持

并行构建与并行扫描分别记录,还取决于工作进程是否可用、配置和构建阶段。

同版本英文证据

PostgreSQL can build indexes while leveraging multiple CPUs in order to process the table rows faster. This feature is known as parallel index build . For index methods that support building indexes in parallel (currently, B-tree, GIN, and BRIN), maintenance_work_mem specifies the maximum amount of memory that can be used by each index build operation as a whole, regardless of how many worker processes were started. Generally, a cost model automatically determines how many worker processes should be requested, if any.

PostgreSQL 18.6 · sql-createindex

查询、运算符与限制

CREATE INDEX name ON table_name USING btree (column_name);

这是语法模板;使用时请替换表、列占位符,并选择兼容的操作符类。

B-tree 能对可按某种顺序排序的数据执行等值查询和范围查询。具体而言,当索引列参与使用下列运算符之一的比较时,PostgreSQL 查询规划器会考虑使用 B-tree 索引:

<   <=   =   >=   >

等价于这些运算符组合的表达式,例如 BETWEEN 和 IN,也可通过 B-tree 索引搜索实现。索引列上的 IS NULL 或 IS NOT NULL 条件也能使用 B-tree 索引。

如果模式是常量,并且锚定在字符串起始位置,优化器也可以对涉及模式匹配操作符 LIKE 和 ~ 的查询使用 B-树索引,例如 col LIKE 'foo%' 或 col ~ '^foo' ,但不能用于 col LIKE '%bar' 。不过,如果你的数据库没有使用 C 区域设置,就需要以一个特殊操作符类来创建该索引,才能支持模式匹配查询的索引化,详见下文 第 11.10 节 。B-树索引也可以用于 ILIKE 和 ~* ,但前提是模式以非字母字符开头,也就是不会受到大小写转换影响的字符。

B-tree 索引也可按排序顺序检索数据。这不总是比直接扫描后排序更快,但通常有帮助。

存储参数

通过 CREATE INDEX … WITH 或 ALTER INDEX … SET 设置索引参数。默认值和实际行为取决于访问方法及所选 PostgreSQL 版本。

fillfactor

控制索引方法尝试将索引页填充到多满。对于 B-树,在初始构建索引时,以及在右侧扩展索引(加入新的最大键值)时,叶子页都会填充到这一百分比。如果页面随后变成全满,就会发生分裂,从而导致磁盘上的索引结构碎片化。B-树默认使用 90 的填充因子,但也可以选择 10 到 100 之间的任意整数值。

对预计会有大量插入和/或更新的表,在 CREATE INDEX 时为 B-树索引设置较低的填充因子会有好处(即在向表批量装载数据之后)。50 到 90 范围内的值可以有效地 “ 平滑 ” B-树索引生命周期早期页面分裂的 速率 (这样降低填充因子甚至可能减少页面分裂的绝对数量,不过这一效果高度依赖工作负载)。 第 65.1.4.2 节 中描述的 B-树自底向上索引删除技术依赖于页面上有一些 “ 额外 ” 空间来存储 “ 额外 ” 的元组版本,因此也会受到填充因子影响(不过通常影响不大)。

在某些其他特定情况下,在 CREATE INDEX 时将填充因子提高到 100 可能有助于最大化空间利用率。只有在完全确定该表是静态的(即永远不会受到插入或更新影响)时,才应考虑这样做。否则,将填充因子设为 100 有 损害 性能的风险:即便只有少量更新或插入,也会导致页面突然大量分裂。

其他索引方法以不同但大致类似的方式使用填充因子;默认填充因子因方法而异。

同版本参数定义

deduplicate_items

控制是否使用 第 65.1.4.3 节 中描述的 B-树去重技术。设置为 ON 或 OFF 可启用或禁用该优化。( ON 和 OFF 的其他拼写形式也被接受,如 第 19.1 节 所述。)默认值为 ON 。

通过 ALTER INDEX 关闭 deduplicate_items 后,新插入不会再触发去重,但此操作本身不会将已有的 posting list 元组转换为标准元组表示。

同版本参数定义

版本比较

目标 PostgreSQL 18.6

这些样本的文档能力状态和存储参数清单没有差异.

比较范围为能力状态和文档中的存储参数名称,不覆盖全部算法、性能特点、参数定义和发布说明变化。

文档记录的历史

PostgreSQL 12 → 13

  • 新增记录的存储参数: deduplicate_items
  • 不再记录的存储参数: vacuum_cleanup_index_scale_factor

PostgreSQL 10 → 11

  • INCLUDE 附加列: 不支持 → 支持
  • 并行索引构建: 未确定 → 支持 (来源覆盖变化)
  • 新增记录的存储参数: vacuum_cleanup_index_scale_factor

PostgreSQL 9.6 → 10

  • 并行索引扫描: 未确定 → 支持 (来源覆盖变化)

PostgreSQL 9.5 → 9.6

  • 仅索引扫描: 未确定 → 支持 (来源覆盖变化)

相关文档与对象

来源与构建标识

原始证据来自英文手册构建 18.6。中文译文另列来源,不将文档结论作为运行时能力测量。

来源指纹
手册构建
PostgreSQL 18.6 Documentation
组合页面 SHA-256
0e39ebd4fddbd990280e62f4503f0bd18765bbd990dccf4cba976b5d47da45e7
手册清单记录的源码归档
18.6
手册清单记录的归档 SHA-256
555610c24d53e4316da5b7d3fc25c279d96856d5e0e23ee308c328c5fa881d9f
  • indexes-types.html: cee340145a2ef5fbd807f66755b10d22bb049e328c460f572f45ad6193e7e4a1
  • catalog-pg-am.html: 579364179365a51945e2edb6481df5d198916c2c725e506f166824dedf08994c
  • hash-index.html: b994550220e1ee05648d09804c9eb2302834e07e261932420a96605d7c9c6140
  • indexam.html: 0a38f7c0ac0541f31e086c83a624e782c15367456578a6dd3329882516bc1080
  • indexes-index-only-scans.html: 2322ec12b82f3fd01ee4072049caaa5a0190148ac68d98c0fcd6eda958828a83
  • indexes-multicolumn.html: c0a799ec49b8ef057a63d465fb1d72a3b81e16d652c28a71734d45592d081202
  • indexes-opclass.html: 07de06abf3a2aff2a891a2789def434d9b76705e54d45ca5338dc13451ae2962
  • indexes-ordering.html: 85fac99c7c66ed19dd021f12b5cc53ce18aa5bfa4b56c8c168317f99b8f12d3b
  • indexes-unique.html: 7c3eac7fa180b22534ff01df0c68155f15b6b360ffe35507c5266059116840db
  • parallel-plans.html: 62207d207bead82b01b59dc119c4f95856f08655cc11d4699a05a40867ed2070
  • sql-createindex.html: 6aa00da55815d13d0355dd25cb1cdb603fa36964993f164d1b6f486011282580

返回 Index AM · 已记录于 PostgreSQL 9.0 至 20;最早样本不代表实际引入版本。