索引 · XB 现场笔记

InnoDB 覆盖索引包含查询所需的列

Fri, 03 Mar 2028 00:00:00 +0000

覆盖索引包含某条查询求值和返回结果所需的列。在 InnoDB 中，二级索引记录还会携带主键列，因此即使二级索引定义没有再次列出主键，某条查询也可能已经被覆盖。覆盖描述的是一条具体查询与某个索引之间的关系，不是给索引贴上标签之后，整张表的所有查询都自动获得同样行为。

坏掉的样子

增加返回列可能使覆盖失效。原本能提供标识和时间戳的索引，不一定包含应用后来开始读取的大载荷。优化器仍然可能沿用这个索引定位匹配记录，再访问聚簇记录取得缺失字段。因此，“用到了索引”和“由索引覆盖查询”是两件不同的事，不能从计划中出现索引名字就直接推导后者。

覆盖也不保证访问范围足够小。一个扫描大量条目的查询，可以完全被索引覆盖，仍然花费很多工作。列顺序、过滤条件、排序要求和行数估计都很重要。不要把 Using index 覆盖标记当作查询很快的证明，也不要把它与 Using index condition 索引条件下推标记混淆；后者描述部分条件在索引层求值，并不证明整个返回投影都在索引里。

InnoDB 的可见性检查还会限制通常所说的“只读索引”解释。二级记录不包含与聚簇记录相同的隐藏事务元数据。遇到删除标记条目，或被更新事务修改过的二级索引页时，可能仍需访问聚簇记录才能获得正确可见版本。因此，在并发多版本活动下，一个覆盖计划并不普遍保证聚簇访问次数永远为零。

快速验证

历史示例保持原样，当前没有 MySQL 8.4，因此本次没有重跑；计划结果仍属于既有运行记录。

准备一台新的 MySQL 8.4 实例，使用能够创建测试模式的客户端会话。既有运行记录中的版本是 MySQL 8.4.11。确认实验模式名尚未使用，遇到非预期 SQL 错误就停止，并保持同一个会话，以保留当前选中的数据库。下面建立一万行数据，其中一百笔已付款订单，并让载荷列明显比索引所需字段更宽：

CREATE DATABASE xbcatm_index_lab;
USE xbcatm_index_lab;
CREATE TABLE orders (
 id INT PRIMARY KEY,
 status VARCHAR(10) NOT NULL,
 created_at DATETIME NOT NULL,
 payload VARCHAR(1000) NOT NULL,
 INDEX by_status_created (status,created_at)
) ENGINE=InnoDB;
INSERT INTO orders
WITH digits(n) AS (
 SELECT 0 UNION ALL SELECT 1 UNION ALL SELECT 2 UNION ALL SELECT 3
 UNION ALL SELECT 4 UNION ALL SELECT 5 UNION ALL SELECT 6
 UNION ALL SELECT 7 UNION ALL SELECT 8 UNION ALL SELECT 9
)
SELECT number+1,IF(MOD(number+1,100)=0,'paid','open'),
 TIMESTAMP '2026-01-01 00:00:00' + INTERVAL (number+1) SECOND,
 REPEAT('x',640)
FROM (SELECT a.n+10*b.n+100*c.n+1000*d.n AS number
 FROM digits a CROSS JOIN digits b CROSS JOIN digits c CROSS JOIN digits d) AS numbered;
ANALYZE TABLE orders;
SELECT COUNT(*),SUM(status='paid') FROM orders;

最后的两个计数应为一万与一百。二级索引明确包含状态与创建时间，InnoDB 隐式提供主键标识。先检查并运行只需要这些值的查询：

EXPLAIN SELECT id,created_at FROM orders WHERE status='paid' ORDER BY created_at,id LIMIT 20;
EXPLAIN ANALYZE SELECT id,created_at FROM orders WHERE status='paid' ORDER BY created_at,id LIMIT 20;
SELECT id,created_at FROM orders WHERE status='paid' ORDER BY created_at,id LIMIT 20;

既有表格计划给出所建索引及覆盖访问标记，实际分析计划显示覆盖索引查找并返回二十行。结果标识依次为一百、二百，直到两千，按照时间戳与标识排序。这是在已经填充数据的表上核对过的实际结果，不是从一个空模式推测查询会采用什么访问路径。

接着，把载荷也加入返回列：

EXPLAIN SELECT id,created_at,payload FROM orders WHERE status='paid' ORDER BY created_at,id LIMIT 20;
EXPLAIN ANALYZE SELECT id,created_at,payload FROM orders WHERE status='paid' ORDER BY created_at,id LIMIT 20;

既有计划仍使用同一个索引，却不再具有覆盖标记；实际分析也变成没有覆盖限定的索引查找。这保持了过滤、排序和索引不变，只改变所需返回列，因而能够明确观察投影变化的影响。实际分析命令会真正执行查询，对真实的大查询使用它时，应把这次诊断本身的执行代价算进去。

最后删除本次实验自己创建的模式：

DROP DATABASE xbcatm_index_lab;

这个小型热缓存实验的时间不能当成吞吐量或延迟基准。调度、缓存和测量本身的开销，可能超过两次二十行查询之间的差别。这里验证的是访问形态与结果内容，而不是承诺物理输入输出减少某个固定比例，更不能据此保证生产请求的高分位延迟必然下降一半。

有意识地承担覆盖成本

给二级索引追加字段会占用存储与缓冲池容量，并在相关索引值变化时增加维护工作。较长的主键也会扩大二级索引条目。应覆盖重要而窄的查询，不要默认把大载荷复制到每个索引里。明确列出返回字段，也有助于后续应用变更在审阅时暴露新的数据访问要求，避免一个查询投影变化悄悄改变成本。

保留新增索引之前，应比较代表性的计划、检查行数、前台延迟以及写入代价。使用真实选择率和并发活动进行验证；安静夹具并没有测量可见性检查需要聚簇访问的频率，也没有测量副本维护这些索引的成本。索引应当通过它实际服务的工作负载证明价值，而不是仅因为一次解释输出里出现了期望的标签。

来源

MySQL 8.4 聚簇索引与二级索引，二级记录携带主键列的机制，已核验 2026-09-12。
MySQL 8.4 EXPLAIN 输出，索引使用与覆盖计划标记，已核验 2026-09-12。
MySQL 8.4 InnoDB 多版本机制，二级索引可见性检查需要聚簇访问的条件，已核验 2026-09-12。

部分索引的写入成本

Tue, 15 Feb 2028 00:00:00 +0000

部分索引筛选的是行，不是裁剪列。给 id 建索引并加上 WHERE status = 'open'，保存的是未关闭行的标识符；状态列决定哪些行进入索引，却不因此成为搜索键。估算维护成本时，这个区别很重要：即使某一列的值没有存进索引键，它仍可能影响更新需要付出的代价。

如果订单表大部分是已关闭的历史记录，把这些行排除在索引之外，确实可能省下大量索引空间。但这不代表历史行可以免费写入，也不保证查询一定更快，更不会消除数据表本身的清理工作。判断收益时，要同时看结构缩小了多少，以及维持正确状态仍需承担哪些写入。

区分成员资格与更新成本

新插入的行不满足谓词时，这一个部分索引不需要为它新增条目。谓词判断、表内存储、其他索引以及正常事务处理仍然存在。把一行从子集外改到子集内，需要新增条目；把它改出子集，则会改变当前查询能看见的成员。旧行版本与过时索引条目的物理回收可能发生在之后，不能把逻辑上退出子集理解成立即释放所有存储空间。

成员资格没有变化，也不等于可以跳过索引维护。未关闭订单的标识符改变了，索引键就需要更新。即使只修改一列与索引无关的备注，只要数据库无法采用堆内元组更新，也就是 HOT，新行版本仍可能需要新的索引条目。因此，“谓词结果不变”不足以证明这次更新很便宜。

对本文讨论的 PostgreSQL 18 B-tree 索引，HOT 要求所有索引定义引用的列值保持不变，包括表达式引用的列和部分索引谓词引用的列；原来那张堆页面还必须容得下新行版本。把状态从已关闭改成已归档，两种状态虽然都不满足谓词，仍然改变了索引依赖的状态列，会阻止 HOT。只修改没有被任何索引引用的备注列，则可能满足条件。

降低表的填充比例可以为页面内更新预留空间，但不是保证成功的开关。检查时必须看整张表的索引集合，另一个索引可能恰好引用备注列，独立阻止这次优化。只盯着准备新增的那个部分索引，会漏掉其他定义施加的限制。

规则还依赖版本和索引方法。PostgreSQL 16 开始允许只改变 BRIN 等汇总索引引用列的更新使用 HOT，汇总信息仍可能需要维护。这项例外不适用于这里的 B-tree 索引。把一个版本、某种索引上的测试结论搬到其他部署之前，应先核对对应版本的文档。

可以使用与值得使用是两回事

规划器必须能够证明，查询条件蕴含部分索引的谓词。只包含未关闭订单的索引，不能单独回答还可能需要已关闭订单的请求。通用计划里的 status = $1 无法提供这个证明；按具体参数生成的定制计划则可能知道传入值。若状态条件本来就是固定的 status = 'open'，仅把其他查询值参数化，并不会抹掉这个事实。

有资格参与选择的索引，仍要与其他访问路径比较成本。表很小或者结果覆盖面很广时，顺序扫描可能更合适。看到计划没有采用部分索引，先检查估算行数、实际行数与缓冲区访问，再判断是不是谓词写法导致无法匹配。机械要求计划永远出现某个索引名，会把性能假设误当成正确性要求；结果是否完整正确与路径是否足够便宜，应该分别验证。

坏掉的样子

积压越来越多，原本很小的未关闭子集也可能占据大部分数据；频繁的状态切换，还可能抵消预期的写入节省。应使用有代表性的查询和状态转换比较，而不是只凭两个索引的体积推导吞吐量。大量重叠的部分索引会增加规划与维护工作，不能把每个报表的过滤条件都独立变成一个索引。

新增切片或删除看起来没人扫描的索引之前，要检查完整索引集合与业务规则。尤其是承担唯一性约束的索引，即使查询扫描次数很低，也可能一直在保护数据完整性。体积变大或扫描次数减少，意味着需要重新评估，不是可以直接删除的充分证据。

快速验证

在可丢弃的 PostgreSQL 18 数据库中，打开一个新的 psql -X -v ON_ERROR_STOP=1 会话，并确认已启用 track_counts，依次运行两个代码块。下面的 SQL 已在 PostgreSQL 18.6 的无套接字单用户模式中执行；尚未验证客户端连接服务器的路径。临时表共有两万行，其中两百行未关闭。显式命名索引，避免依赖数据库自动生成的名字。

BEGIN;
CREATE TEMP TABLE partial_cost_demo (
 id integer NOT NULL,
 status text NOT NULL,
 note integer NOT NULL
) WITH (fillfactor=50);
INSERT INTO partial_cost_demo
SELECT g, CASE WHEN g % 100 = 0 THEN 'open' ELSE 'closed' END, 0
FROM generate_series(1,20000) AS g;
CREATE INDEX cost_all_id ON partial_cost_demo (id);
CREATE INDEX cost_open_id ON partial_cost_demo (id) WHERE status='open';
ANALYZE partial_cost_demo;
SELECT pg_relation_size('cost_all_id') AS full_bytes,
 pg_relation_size('cost_open_id') AS partial_bytes;
EXPLAIN (ANALYZE, BUFFERS, TIMING OFF)
SELECT id FROM partial_cost_demo WHERE status='open' ORDER BY id LIMIT 5;
SELECT id FROM partial_cost_demo WHERE status='open' ORDER BY id LIMIT 5;

查询结果应为一百、两百、三百、四百和五百。部分索引预计占用更少字节，但不要要求体积精确等于全量索引的百分之一，页面本身也有开销。记录实际选中的计划，不要断言某一种固定形状。全量索引与部分索引使用同样的键，提供体积对照，同时也会参与访问路径竞争。

UPDATE partial_cost_demo SET note=1 WHERE id=100;
SELECT n_tup_upd, n_tup_hot_upd FROM pg_stat_xact_user_tables
WHERE relid='partial_cost_demo'::regclass;
UPDATE partial_cost_demo SET status='archived' WHERE id=101;
SELECT n_tup_upd, n_tup_hot_upd FROM pg_stat_xact_user_tables
WHERE relid='partial_cost_demo'::regclass;
SELECT count(*) FROM partial_cost_demo WHERE status='open';
ROLLBACK;

这里使用当前事务的统计视图，计数会随本事务中的操作持续更新，不必等待累计统计刷新。更新总数应从一次增加到两次。备注更新可能增加 HOT 次数；状态改变不应增加 HOT 次数，即使它前后都不属于未关闭子集。隔离测试中，两次记录的更新总数与 HOT 次数分别为（一，一）和（二，一），未关闭行仍有两百行。全量和部分索引的大小分别为四十六万六千九百四十四与一万六千三百八十四字节，选中的仅索引扫描仍访问了五次堆。这里记录的是特定实验的观察值，不是所有环境都应相同的结果。回滚后实验对象和数据已被移除。

这个练习把索引子集大小与 HOT 条件分开观察，并没有测量长期运行的生产负载。临时表上的耗时不能证明生产 WAL 节省，也不能证明持续写入吞吐量。真正的上线判断还需要同等负载、同等索引集合，以及有代表性的页面空间和更新分布。

来源

PostgreSQL 18 部分索引，成员资格、逻辑蕴含与过量部分索引，已核验 2026-10-15。
PostgreSQL 18 HOT，更新条件与页面空间，已核验 2026-10-15。
PostgreSQL 18 HOT 实现说明，谓词列依赖和元组链，已核验 2026-10-15。
PostgreSQL 16 发行说明，第十六版引入的 BRIN 例外，已核验 2026-10-15。
PostgreSQL 18 PREPARE，定制计划与通用计划，已核验 2026-10-15。
PostgreSQL 18 统计系统，当前事务的统计计数，已核验 2026-10-15。
PostgreSQL 18 EXPLAIN，实际执行与缓冲区测量，已核验 2026-10-15。
PostgreSQL 18 体积函数，关系主数据分支的大小，已核验 2026-10-15。

哈希索引复核碰撞，也要维护变化的键

Mon, 24 Jan 2028 00:00:00 +0000

PostgreSQL 哈希索引先利用哈希码缩小等值查询的候选范围，再回到表中核对原始值。哈希匹配只说明“可能相等”，不能直接证明相等。两个不同值可能具有相同哈希码，不同哈希码也可能映射到同一个桶。正常复核存在时，碰撞和共享桶都不意味着查询会返回错误结果；它们是实现需要处理的普通情况，而不是可以忽略的例外。

桶里究竟保存什么

索引条目包含四字节哈希值和指向表元组的引用，不保存完整的被索引列值。桶映射把查询导向相关索引页面。桶是共享存储空间，并不是给每个不同键单独分配一个专属位置。一个桶的主页装满后，可以继续连接溢出页，查询这个桶时也需要访问这些页面。因此，“一次算出桶”不等于“永远只读取一个页面”。

PostgreSQL 可以在单个索引页内部按哈希码排序，以便加速局部搜索，但这不会提供原始列值的顺序。哈希索引不能满足键范围或有序输出，只支持单列等值访问，不能强制唯一性，也不支持 IS NULL。B-tree 仍然可以服务等值查询，同时支持更广的一组操作，不能因为键看起来适合哈希就自动排除其他候选。

由于条目中没有原始值，哈希扫描是有损候选扫描，需要用表中实际值复核。因此，碰撞可以在执行计划中表现为 Rows Removed by Index Recheck。这说明数据库正确剔除了只在哈希上匹配的候选，而不是把两个碰撞值都当成相等返回。解读这项指标时，应把候选数量与最终答案区分开。

坏掉的样子

把索引键更新描述为“只碰一个桶”，掩盖了实际工作。修改被索引列会改变元组对应的索引值，新条目可能进入另一个桶。PostgreSQL 使用行版本与延后索引清理，旧引用不一定立刻从结构中消失。数据增长还可能触发桶分裂，溢出页也会增加读写。因此不能用一个理想化的哈希表赋值过程来解释数据库的全部更新成本。

高度重复的值、快速增长的表，与近乎唯一而稳定的等值负载，表现可能很不一样。哈希查询不是无条件的恒定延迟承诺。现代 PostgreSQL 的哈希索引支持崩溃恢复，但持久性既不会消除维护成本，也不会让它突然具备唯一性约束能力。读性能、写维护和数据契约必须分别确认。

快速验证

在可丢弃的 PostgreSQL 18 数据库中，用 psql 执行下面代码。它建立二十万个采用 C 排序规则的临时文本键，使用当前服务器自己的 hashtext 找到一组碰撞，再验证等值查询和键更新。实验没有把哈希码当成跨版本稳定的业务标识，最后回滚会移除所有夹具。

\set ON_ERROR_STOP on
BEGIN;
CREATE TEMP TABLE hash_items (key text COLLATE "C");
INSERT INTO hash_items SELECT 'key-'||g FROM generate_series(1,200000) AS g;
CREATE TEMP TABLE collision_pair AS
SELECT min(key) AS a,max(key) AS b FROM hash_items
GROUP BY hashtext(key) HAVING count(*)>1 ORDER BY hashtext(key) LIMIT 1;
SELECT a AS collision_a,b AS collision_b FROM collision_pair \gset
SELECT a,b,hashtext(a),hashtext(b) FROM collision_pair;
CREATE INDEX hash_items_key ON hash_items USING hash(key);
ANALYZE hash_items;
EXPLAIN (ANALYZE, BUFFERS, TIMING OFF) SELECT key FROM hash_items WHERE key=:'collision_a';
UPDATE hash_items SET key='changed-'||key WHERE key=:'collision_a';
SELECT count(*) AS old_key_rows FROM hash_items WHERE key=:'collision_a';
SELECT count(*) AS new_key_rows FROM hash_items WHERE key='changed-'||:'collision_a';
DO $$ BEGIN
 IF (SELECT hashtext(a)=hashtext(b) AND a<>b FROM collision_pair) IS DISTINCT FROM true THEN
 RAISE EXCEPTION 'fixture did not establish a collision';
 END IF;
 IF (SELECT count(*) FROM hash_items h JOIN collision_pair p ON h.key=p.a) <> 0 OR
 (SELECT count(*) FROM hash_items h JOIN collision_pair p ON h.key='changed-'||p.a) <> 1 OR
 (SELECT count(*) FROM hash_items h JOIN collision_pair p ON h.key=p.b) <> 1 THEN
 RAISE EXCEPTION 'hash lookup or indexed update returned wrong keys';
 END IF;
END $$;
ROLLBACK;

PostgreSQL 18.6 中找到的两个键是 key-129539 与 key-7295，哈希码都是 -1960436116。等值计划使用 hash_items_key，最终只返回一行，同时报告一行被索引复核移除。两段字符串虽然哈希相同，却仍然是不同的值。这是反对“哈希码没有碰撞”这一错误假设的实际负向验证，不能用普通的无碰撞点查替代。

将第一个键改成带 changed- 前缀的新值后，旧值查到零行，新值查到一行，另一条碰撞记录仍然查到一行。最终断言分别验证这三件事，并确认原始两个值确实具有相同哈希而内容不同。仅仅看到更新命令成功，还不足以证明同桶或同哈希的其他记录没有受到错误影响。

具体碰撞键和计划形状来自这一版本的实测。如果其他环境没有找到碰撞对，脚本应停止，不能宣称已经验证碰撞复核。即使换个环境找到另一组键，语义要求仍然不变：精确相等只能返回原始值符合条件的记录；修改一个值，不得因为另一个值哈希相同而改变它。固定的结果契约比固定某个内部哈希码更重要。

把维护也放进性能评估

使用有代表性的分布一起测量页面访问、等值延迟、更新行为和索引大小。VACUUM 可以移除失效引用、回收溢出页供结构内部复用，但不会缩小哈希索引的桶数量，也不会把这部分分配直接归还操作系统。重建属于另外的维护操作，本身需要成本。较小的哈希条目确实可能有价值，但只有完整负载比较才能判断它是否抵得过复核、溢出页和写维护开销。

来源

PostgreSQL 18：哈希索引，碰撞复核与桶维护，已核验 2026-09-10。
PostgreSQL 18：索引类型，B-tree 与哈希索引支持的条件，已核验 2026-09-10。

部分唯一性约束保护有效子集

Fri, 15 Oct 2027 00:00:00 +0000

部分索引只为满足谓词的行保存索引项。需要的子集很小时，它可以缩小索引，但也可以表达只对这个子集生效的完整性规则。例如，同一个座位允许保留多条历史预订，却只能有一条当前有效预订。部分唯一索引可以把这条规则放在数据库边界上执行，而不只是提高某条查询的速度。

成员资格随谓词变化

CREATE INDEX ... WHERE active 只包含 active 为 true 的行，false 和 null 都不满足条件。是否允许 null 是独立的模型选择；下面实验把 active 定义为非空，使每条预订明确处于有效或无效状态。索引键也不必就是谓词中出现的列：这里用 seat 作为键，用 active 决定哪些行参与。

普通写入会改变成员资格。无效记录变成有效记录时，必须进入索引并接受检查；有效记录失效后，则离开当前有效子集。这个边界不是一旦建索引就永远固定的历史分界线。每次写入仍要判断谓词，状态切换也有维护成本，所以索引更小不意味着所有更新都免费，更不能无条件承诺写入一定更快。

唯一性可以只针对子集

在 seat 上建立 WHERE active 的唯一索引，会拒绝同一个座位出现两条有效记录，却允许任意多条无效历史记录。即使没有 SELECT 使用这个索引，数据库仍会执行唯一性检查。因此查询加速与数据完整性是保留索引的两种不同理由，不能只看扫描计数为零就把承担约束的索引删除。

应用先查“有没有”再插入，比数据库约束弱，因为另一个事务可能在检查与写入之间插入。唯一索引会在 PostgreSQL 中协调冲突写入，失败方需要处理唯一性错误或明确选择的冲突策略。下面夹具按确定顺序验证拒绝行为；并发协调属于数据库约束契约，不代表已经实现支付、扣款和跨服务预订的完整业务流程。

查询也要表达同一边界

规划器把部分索引用于访问路径时，必须能够证明查询条件蕴含索引谓词。仅按 seat 查询，并不能证明调用方只需要有效记录，因为历史记录也可能匹配。显式查询 active 记录才可能符合条件，但小表仍可能采用更便宜的顺序扫描。逻辑上相似的表达式，也只有在规划器能够识别其蕴含关系时才有用，不能仅凭人眼觉得相近。

也不要用数百个互相重叠的部分索引模拟分区。规划与维护成本会增长，优化器不会自动把这些独立索引当成一套协调的分区结构。谓词应来自稳定的工作负载或明确完整性需求，再通过真实查询与状态转换验证。建立索引不是给数据打上一个永不变化的标签，而是维护一个持续受规则约束的子集。

坏掉的样子

查询忘写有效状态条件时，可能把旧预订和当前预订一起返回，而唯一索引本身完全没有失效。反过来，应用把这个索引误当成全表唯一，也可能在业务层错误拒绝合法历史。应写清规则约束的是所有行还是当前子集，并同时测试这两类数据。否则列表页、恢复旧记录和导入流程很容易对同一座位产生不同理解。

重新激活失败是另一个关键边界。把旧记录改回 active，可能与当前持有人冲突。失败后旧记录应该仍保持无效，并向调用方报告冲突，不能悄悄替换已有有效预订。批量导入与状态迁移也必须接受同样检查，不能因为它们是运维任务就绕开当前有效唯一性；这样才能让不同写入入口共享同一规则。

快速验证

保存为 partial-unique.sql，使用 psql -X -v ON_ERROR_STOP=1 -f partial-unique.sql 连接可丢弃的 PostgreSQL 18 数据库。实验只创建会话临时预订表，不接触真实座位库存；所有记录和状态变化都在代码中给出。

\set ON_ERROR_STOP on
BEGIN;
CREATE TEMP TABLE reservations (id integer PRIMARY KEY, seat text NOT NULL, active boolean NOT NULL);
CREATE UNIQUE INDEX one_active_seat ON reservations (seat) WHERE active;
INSERT INTO reservations VALUES (1,'A1',true),(2,'A1',false),(3,'A1',false);
DO $$ BEGIN
 INSERT INTO reservations VALUES (4,'A1',true);
 RAISE EXCEPTION 'two active reservations accepted';
EXCEPTION WHEN unique_violation THEN RAISE NOTICE 'active duplicate rejected';
END $$;
UPDATE reservations SET active=false WHERE id=1;
INSERT INTO reservations VALUES (4,'A1',true);
DO $$ BEGIN
 UPDATE reservations SET active=true WHERE id=2;
 RAISE EXCEPTION 'reactivation bypassed uniqueness';
EXCEPTION WHEN unique_violation THEN RAISE NOTICE 'conflicting reactivation rejected';
END $$;
SELECT active,count(*) FROM reservations GROUP BY active ORDER BY active;
SELECT id FROM reservations WHERE active AND seat='A1';
DO $$ BEGIN
 IF (SELECT id FROM reservations WHERE active AND seat='A1') IS DISTINCT FROM 4 THEN
 RAISE EXCEPTION 'wrong active reservation';
 END IF;
 IF (SELECT count(*) FROM reservations WHERE NOT active) <> 3 THEN
 RAISE EXCEPTION 'history was not preserved';
 END IF;
END $$;
ROLLBACK;

最初的有效重复被拒绝，而两条历史重复成功保留。把一号预订设为无效后，四号预订可以取得该座位；再把二号重新激活则失败，因为四号仍有效。最后应有三条无效记录、一条有效记录，有效标识为四。断言同时检查当前持有人与历史数量，避免只验证拒绝消息而遗漏错误的数据变更。

这些检查在 PostgreSQL 18.6 通过。异常块只捕获预期的唯一性违反；如果本应失败的操作意外成功，后面的不同异常会让脚本失败。最后回滚移除夹具。实验验证子集成员资格与唯一性转换，不证明支付原子性、分布式库存一致性，也没有测量巨大历史表上的性能收益。

来源

PostgreSQL 部分索引，谓词成员资格与部分唯一性，已核验 2026-10-15。
PostgreSQL CREATE INDEX，唯一索引检查与谓词，已核验 2026-10-15。

覆盖索引有条件地避免堆访问

Thu, 14 Oct 2027 00:00:00 +0000

覆盖索引包含某一条查询需要的值，PostgreSQL 有时可以通过 index-only scan 直接返回它们，避免访问对应的堆元组。这里的“有时”很关键：列是否齐全属于结构条件，执行时能否真正跳过堆访问，还取决于可见性信息。计划里出现 Index Only Scan，并不能单独证明没有访问表数据，更不能据此宣称任何写入状态下都能省掉堆读取。

覆盖实际返回的列

按 sku 查价格时，可以建立 sku 的 B-tree，并用 INCLUDE (price) 把价格作为附加值存进去。搜索由 sku 键引导，附加的 price 不会自动成为第二个搜索键，也不提供按价格排序的顺序。如果这是唯一索引，唯一性约束针对键列，而不是键与附加列的整体组合。这些区别决定它究竟能回答哪些查询。

查询后来增加返回列，就可能破坏覆盖前提。例如 description 不在索引中，执行器需要从其他位置取得它，通常就是堆表。随手改成 SELECT 星号，也可能把原本专门优化的查找变成另一种访问模式。应从实际过滤条件和投影列出发，结合表达式与可见性需求设计，而不是把全部字段都塞进一个预想中的万能覆盖索引。

并非所有索引方法都能还原 index-only 执行所需的完整值。B-tree 支持这种扫描，GIN 通常保存的是从原值提取的键，而不是完整原值，因此不支持 index-only scan。索引不仅要包含或能够还原所需数据，也要支持对应操作。其他数据库也使用“覆盖索引”这个名称，但不能据此把 PostgreSQL 的可见性机制直接套过去。

可见性映射决定是否访问堆

PostgreSQL 必须判断候选元组是否对当前 MVCC 快照可见，索引项没有保存全部所需可见性信息。Index-only scan 会检查堆页在 visibility map 中的 all-visible 位；该位已设置时，才能直接返回索引中的值，而不读取堆元组。这样省下的是堆访问，仍然需要读取索引和可见性映射，并不等于完全没有 I/O。

写入可能清除页的 all-visible 状态，导致之后的查询重新访问堆，即使计划名称没有改变。VACUUM 可以在页内元组满足可见性条件时设置该状态，长事务和持续更新都会影响这一过程。它是页级属性，不是某个单独字段的属性；同一页上其他行被修改，也可能影响当前行的可见性检查路径。因此“这一行没改过”也不能直接推出零堆访问。

坏掉的样子

最常见的误判是只看 EXPLAIN 的计划标签就宣布优化成功。应在 EXPLAIN ANALYZE 中同时查看 Heap Fetches、相关缓冲区和实际返回值。频繁写入的表可能不断需要堆检查，读取收益下降，却仍承担附加值的复制与维护成本。每次业务写入后都运行 VACUUM，并不能代替对真实读写比例和维护成本的评估。

宽大的附加列还会占用磁盘和缓存，增加索引维护工作，甚至超过索引元组尺寸限制。更新 INCLUDE 列需要维护索引，也可能阻止原本可行的 heap-only update。应只覆盖读收益足以抵偿写入和存储成本的字段；覆盖索引不是免费物化的整表副本，也不能只用一次静态查询的耗时决定是否值得长期保留。

快速验证

把 SQL 保存为 covering.sql，运行 psql -X -v ON_ERROR_STOP=1 -f covering.sql，连接可丢弃的 PostgreSQL 18 数据库。保持 psql 默认自动提交，不要在外面加 BEGIN，因为 VACUUM 不能在显式事务块中运行。实验表是会话临时表，不会修改其他连接的数据，断言失败退出后临时表也会随会话消失。

\set ON_ERROR_STOP on
CREATE TEMP TABLE products (sku integer, price integer);
INSERT INTO products SELECT g, g*10 FROM generate_series(1,10000) AS g;
CREATE INDEX products_price_lookup ON products (sku) INCLUDE (price);
VACUUM (ANALYZE) products;
EXPLAIN (ANALYZE, BUFFERS, TIMING OFF)
SELECT price FROM products WHERE sku=4321;
UPDATE products SET price=price+5 WHERE sku=4321;
EXPLAIN (ANALYZE, BUFFERS, TIMING OFF)
SELECT price FROM products WHERE sku=4321;
VACUUM (ANALYZE) products;
EXPLAIN (ANALYZE, BUFFERS, TIMING OFF)
SELECT price FROM products WHERE sku=4321;
DO $$ BEGIN
 IF (SELECT price FROM products WHERE sku=4321) IS DISTINCT FROM 43215 THEN
 RAISE EXCEPTION 'covering lookup returned an obsolete price';
 END IF;
END $$;
DROP TABLE products;

第一次 VACUUM 让静止夹具满足无堆读取条件。在 PostgreSQL 18.6 上，三个计划都显示 Index Only Scan，但 Heap Fetches 依次是零、价格更新后的二、再次 VACUUM 后的零。断言同时确认返回的新价格是 43215，而不是旧索引值。实验最后显式删除临时表，避免把清理当成读者需要猜测的步骤。

中间的具体访问次数可以随实现和页状态变化，关键是相同计划标签下仍可能发生堆访问。Heap Fetches 统计堆访问，并不等于物理磁盘读取次数，所需页仍可能已经在缓存中。这个受控实验也不承诺生产中一次 VACUUM 就让所有页立刻 all-visible。真正评估覆盖收益时，应观察代表性查询在实际更新活动前后的表现，同时计算附加数据带来的维护成本，而不是只挑清理刚完成时的最好结果。

来源

PostgreSQL index-only 扫描，可见性映射与附加值，已核验 2026-09-10。
PostgreSQL CREATE INDEX，INCLUDE 语义与索引限制，已核验 2026-09-10。

小表上全表扫描可能更快

Thu, 16 Sep 2027 00:00:00 +0000

索引用存储和写入成本，换取减少读取工作的机会。表很小，或者谓词选中大部分数据时，全表扫描可能更快，但行数与选择性都不能单独决定胜负。查询需要哪些列、排序要求、缓存状态、行宽和可用访问路径，都会改变比较结果。首先明确实际查询必须返回什么，再判断哪种访问方法做了更多有用工作。

看清两条路径实际做什么

B 树范围扫描并不是每匹配一个索引条目，都重新从根节点下降。定位范围起点后，可以沿相邻条目继续前进。非覆盖索引还可能需要回表取得缺少的列；宽谓词下，这部分工作可能成为主要成本。覆盖索引能够省去这些读取，因此，即使查询命中多数行，索引也仍有可能更划算，不能把宽谓词与索引无用直接画等号。

页很重要，但不是唯一成本。PostgreSQL 默认的 seq_page_cost 与 random_page_cost 是优化器使用的相对估计，不是毫秒，也不是每返回一行就机械收取一次的费用。缓存、数据相关性、CPU 工作、位图扫描与仅索引扫描，都影响计划选择。SQLite 普通表把行放在按 rowid 组织的 B 树中，与 PostgreSQL 堆表存储不同，不能直接把一种引擎测得的性能比例套到另一种引擎。

SQLite 的 PRAGMA page_count 返回整个数据库文件的页数，包括索引和其他对象，不能当作某个指定表的独立页数。逻辑页遍历也不保证磁盘上的连续物理读取。比较时应保持统计对象范围一致，记录页大小、模式、负载宽度和缓存条件，不能只报告行数，再把其他成本差异全部归因于扫描或索引。

保留历史测量的适用范围

此前笔记记录了 SQLite 3.53、二兆字节页缓存下的结果。宽谓词的扫描与索引时间，在一千行时为 0.04 与 0.05 毫秒，在五万行时为 1.79 与 6.61 毫秒，在百万行时为 44.37 与 531.18 毫秒。同一百万行表的高选择性查询，索引为 0.61 毫秒，扫描为 17.88 毫秒。相同行数的窄、宽负载样本还分别记录了十二与一千零十页，以及 0.02 与 1.30 毫秒。

这些是历史观察，不是通用阈值，也不是本轮重新取得的测量。此次审阅没有此前的数据生成器及完整基准环境，因此下面提供独立、可复现的比较，并输出实际运行时版本。它不声称重现历史时间、页数或自动优化器选择。记录旧观察与建立新实验可以同时进行，但不能把新实验的成功当作旧数字已经复核。

坏掉的样子

某个租户持续增长，可能让旧选择性估计失效，而所有查询仍然返回正确结果。统计信息只是一个调查方向，不是原因已经确定：参数变化、覆盖关系、缓存状态或竞争负载，也可能让同一计划变慢。强制长期使用某条路径之前，应比较估计工作量与实际工作量，确认问题出在哪里，再决定是否需要改索引、查询或维护策略。

新统计也不保证所有宽范围谓词都选择扫描。SQLite 构建时可能启用不同的可选统计支持，计划文本也可能随版本改变。SCAN 甚至可能表示覆盖索引扫描，而不一定是表扫描。要阅读完整计划，并比较等价查询的结果，不能把某一个关键词变成正确性判据，更不能因为计划没有按预想翻转，就宣布数据库违反了契约。

快速验证

保存为 scans.py 后执行 python3 scans.py。脚本使用 Python 自带的 SQLite 绑定，在自己创建的临时目录建立数据库，不会打开现有应用数据。三种路径对宽谓词都必须返回二百八十八万，对高选择性谓词都必须返回三千二百。七轮交替顺序的热缓存样本报告中位数，但不会断言哪条路径一定更快，避免把环境相关时序当成功能要求。

from pathlib import Path
from tempfile import TemporaryDirectory
from statistics import median
from time import perf_counter
import sqlite3

with TemporaryDirectory(prefix="scan-crossover-") as directory:
 db = sqlite3.connect(Path(directory) / "fixture.db")
 try:
 db.executescript("""CREATE TABLE events(id INTEGER PRIMARY KEY, tenant INTEGER, payload TEXT);
 CREATE INDEX events_tenant ON events(tenant);""")
 db.executemany("INSERT INTO events VALUES(?,?,?)",
 ((i, i % 1000, "x" * 64) for i in range(50000)))
 db.commit()
 db.execute("ANALYZE")
 print("SQLite", sqlite3.sqlite_version)
 print("database pages", db.execute("PRAGMA page_count").fetchone()[0],
 "page size", db.execute("PRAGMA page_size").fetchone()[0])
 for predicate, expected in [("tenant < 900", 2880000), ("tenant = 7", 3200)]:
 base = "SELECT sum(length(payload)) FROM events {} WHERE " + predicate
 paths = {"chosen": "", "scan": "NOT INDEXED", "index": "INDEXED BY events_tenant"}
 queries = {name: base.format(clause) for name, clause in paths.items()}
 samples = {name: [] for name in queries}
 for name, query in queries.items():
 assert db.execute(query).fetchone()[0] == expected
 print(predicate, name, db.execute("EXPLAIN QUERY PLAN " + query).fetchall())
 for repeat in range(7):
 names = list(queries) if repeat % 2 == 0 else list(reversed(queries))
 for name in names:
 start = perf_counter()
 result = db.execute(queries[name]).fetchone()[0]
 samples[name].append((perf_counter() - start) * 1000)
 assert result == expected
 print("warm median ms", {k: round(median(v), 3) for k, v in samples.items()})
 old = db.execute("SELECT stat FROM sqlite_stat1 WHERE idx='events_tenant'").fetchone()[0]
 db.execute("UPDATE events SET tenant=5")
 db.commit()
 stale = db.execute("SELECT stat FROM sqlite_stat1 WHERE idx='events_tenant'").fetchone()[0]
 assert stale == old
 db.execute("ANALYZE")
 fresh = db.execute("SELECT stat FROM sqlite_stat1 WHERE idx='events_tenant'").fetchone()[0]
 assert fresh.split()[:2] == ["50000", "50000"] and fresh != old
 print("statistics before/stale/fresh", old, stale, fresh)
 try:
 db.execute("SELECT * FROM events INDEXED BY absent_index")
 except sqlite3.OperationalError as error:
 assert "no such index" in str(error), error
 else:
 raise AssertionError("missing required index was silently ignored")
 print("missing INDEXED BY target rejected")
 finally:
 db.close()

负载表达式需要 tenant 索引中没有的数据，因此这里比较的是非覆盖路径。INDEXED BY 要求使用指定索引，并非温和建议；缺少索引的负向对照会明确失败。此处 NOT INDEXED 禁用次级索引，但在别的查询中并不禁止 rowid 查找。这些控制用于诊断，不应未经理由就复制到生产查询中，以免将某次测量得到的选择永久固定。

数据被改成同一个租户以后，sqlite_stat1 在 ANALYZE 之前保持旧值，更新后记录五万行共享同一个键。这个断言验证统计维护，而不是保证计划一定翻转。生产中应遵循当前 SQLite 版本建议的 PRAGMA optimize 流程，并为较昂贵的分析选择合适时机，避免把一次性实验里的维护命令不加判断地放进每个请求。

实验预热数据，只测一个进程，没有竞争写者，因此不能建立冷存储延迟、生产并发或长期索引成本结论。性能测试应保留代表性分布和实际投影，并随表增长重复检查。今天可以接受的扫描，可能在没有任何正确性错误的情况下变贵；要追踪的是业务所需结果的成本，而不只是某个计划名字是否保持不变。

来源

SQLite 查询规划，范围遍历、回表和覆盖索引，已核验 2026-10-15。
SQLite EXPLAIN QUERY PLAN，SCAN/SEARCH 含义和不稳定的展示格式，已核验 2026-10-15。
SQLite PRAGMA page_count，数据库整体页数，已核验 2026-10-15。
SQLite ANALYZE，统计信息与建议的 optimize 流程，已核验 2026-10-15。
SQLite INDEXED BY，索引要求与 NOT INDEXED 范围，已核验 2026-10-15。
PostgreSQL 优化器代价常量，相对成本与缓存假设，已核验 2026-10-15。
PostgreSQL 使用 EXPLAIN，行数估计、位图扫描与仅索引扫描，已核验 2026-10-15。

组合索引贴合多列的查询

Wed, 15 Sep 2027 00:00:00 +0000

复合 B-tree 索引先按第一个键排序，再在第一个键相同的组内按下一个键排序。这种元组顺序可以让“某个租户的一段时间”很容易定位。应理解的是条件能缩小多少索引扫描范围，而不是禁止查询后面的列，也不是要求 WHERE 中的条件必须按建索引的顺序书写。这几个概念混在一起，会导致错误的索引设计。

排序的是键，不是 SQL 条件

对于 (tenant, happened) 索引，tenant 等值条件加 happened 范围条件描述了树中的一小段。PostgreSQL 可以定位这一段，而不用检查所有租户。即使把时间条件写在 WHERE 的前面、租户条件写在后面，逻辑上的合取关系也没有改变。数据库定义中的键顺序与查询文本的书写顺序，是两件不同的事情，不能拿文本位置判断索引是否可用。

通常，前导列的等值条件和第一个非等值键上的范围条件，决定必须扫描的区间。更后面的键条件仍可在索引中检查，即使不能继续缩小一个简单连续区间，也可能减少访问堆表的次数。调换索引键会改变这些机会，但不意味着某种排列在所有查询中都完全无用。需要结合查询实际要求的范围和返回列判断。

后面的键仍可能有用

PostgreSQL 18 在合适时可以使用 B-tree skip scan：如果遍历缺少等值条件的前导键取值，并在每组内重新搜索，比读取大部分索引更便宜，就可能采用这种路径。只有少数几个租户时，仅过滤 happened 也可能通过各租户分组完成查找；前导键不同值很多时，这种重复搜索可能太贵，规划器便可能选择顺序扫描或其他索引。

即使没有合算的 skip scan，某些只涉及后面键的条件仍可能扫描复合索引。问题是成本、覆盖范围与选择性，不是 SQL 是否合法，也不是索引必然被忽略。不能把“最左前缀”这种便于记忆的说法扩展成绝对禁令，尤其在目标数据库明确支持其他访问路径时。版本和真实计划必须优先于口号。

把排序和工作负载一起考虑

固定 tenant 后，后面的 happened 顺序可以支持该租户的时间排序。但跨多个租户时，索引先按租户分组，不会直接提供全局时间顺序。Bitmap 扫描也不保留索引顺序，仍可能需要单独排序。因此应看完整计划，而不是看到索引包含排序列就断言不会发生 Sort。LIMIT 对尽快返回前几行的需求也会改变最合适的路径。

“等值列在前、范围列在后”是一个查询形状的起点，并不是“永远把选择性最高的列放第一”的统一算法。多个查询共享的前缀、连接、排序方向、参数分布和写入成本都会影响选择。比较真正反复出现的查询，再保留必要的最小索引集合。重复且宽大的索引即使没有读者，也会占用缓存和写入维护资源。

坏掉的样子

团队可能为租户内查询建立 (tenant, happened)，随后增加全局时间线，却假定两者效率相同。新查询的顺序要求和过滤范围已经不同，需要重新评估。另一种回归来自测试参数：一个小租户的计划很好，不代表拥有大部分行的租户也同样便宜。同一条参数化 SQL 面对不同数据分布，成本可能差很多，统计信息和代表性参数比单次截图更可靠。

错误规则也会带来不必要的索引变更。因为“原索引绝不可能查后列”而为每个后缀新增索引，可能重复已有能力；反过来，相信 skip scan 总能补救缺失前缀，又可能掩盖昂贵路径。修改数据库结构前，应检查实际行数、缓冲区、排序与访问方式，说明哪个真实查询获得了什么改善。

快速验证

把代码保存为 composite.sql，用 psql -X -v ON_ERROR_STOP=1 -f composite.sql 连接可丢弃的 PostgreSQL 18 数据库。临时夹具包含四个租户取值和两万个事件编号，最后回滚删除全部实验对象，不依赖已有表或数据。

\set ON_ERROR_STOP on
BEGIN;
CREATE TEMP TABLE events (tenant integer, happened integer, body text);
INSERT INTO events SELECT g % 4, g, repeat('x',40) FROM generate_series(1,20000) AS g;
CREATE INDEX events_tenant_time ON events (tenant, happened);
ANALYZE events;
EXPLAIN (ANALYZE, BUFFERS, TIMING OFF)
SELECT happened FROM events WHERE tenant=2 AND happened BETWEEN 100 AND 120
ORDER BY happened;
SELECT array_agg(happened ORDER BY happened) AS matching_times
FROM events WHERE happened BETWEEN 100 AND 120 AND tenant=2;
EXPLAIN (ANALYZE, BUFFERS, TIMING OFF)
SELECT tenant FROM events WHERE happened=12346;
DO $$ BEGIN
 IF (SELECT array_agg(happened ORDER BY happened) FROM events
 WHERE happened BETWEEN 100 AND 120 AND tenant=2)
 IS DISTINCT FROM ARRAY[102,106,110,114,118] THEN
 RAISE EXCEPTION 'wrong composite range';
 END IF;
 IF (SELECT tenant FROM events WHERE happened=12346) IS DISTINCT FROM 2 THEN
 RAISE EXCEPTION 'suffix predicate lost the row';
 END IF;
END $$;
ROLLBACK;

租户范围查询精确返回 102,106,110,114,118，把 WHERE 条件反过来书写时结果相同。在 PostgreSQL 18.6 上，它使用 bitmap index scan 后再排序；仅按后列查询的语句通过带重复索引搜索的 index-only scan 返回租户二，直接证明没有 tenant 等值条件也存在可用路径。两种计划不同，但都符合各自的逻辑结果。

具体计划名称、缓冲区计数和搜索次数是这份数据上的观测，不是任何配置下都必须出现的常量。断言验证结果语义，性能判断还应增加前导键的不同取值数量，测量后列访问在真实分布下是否仍值得使用。这样才能把“索引可以参与”与“该索引在这个负载下划算”分开。

来源

PostgreSQL 多列索引，前导条件和 skip scan，已核验 2026-09-10。
PostgreSQL 索引与 ORDER BY，有序扫描与排序选择，已核验 2026-09-10。

Postgres JSONB 搭配 GIN 做灵活查询

Wed, 28 Jul 2027 00:00:00 +0000

PostgreSQL 的 JSONB 列可以容纳形态不同的文档，但高效查询仍要求条件与索引有准确的对应关系。对整篇文档建立 GIN 索引，只能支持特定的 JSONB 算子，不能自动加速所有从文档提取字段的表达式。先确定数据类型和查询语义，再选择索引，才能避免建完索引却没有收益。

让算子与索引对应

包含条件 payload @> '{"status":"pending"}' 检查文档是否包含该键及对应的 JSON 字符串值。采用默认 jsonb_ops 操作符类时，整列 GIN 可以支持包含、顶层键存在判断，以及能够提取索引条件的 JSON 路径查询。索引保存可检索的组成部分；位图堆扫描仍可能访问表，并重新检查候选行，不能把它理解为完全不用回表。

payload->>'status' = 'pending' 则是在比较提取后的文本。payload 上的 GIN 并不是这个文本表达式的索引。对 (payload->>'status') 建立 B-tree 表达式索引，才与标量等值查询对应。如果很多查询需要对 status 排序、关联或施加约束，独立的有类型列可能更清楚，也能减少不断从灵活文档中推导字段的成本。

不能未经类型检查，就把所有文本条件改写成包含条件。JSON 数字和 JSON 字符串经过文本提取后可能得到相同文本，但包含算子会区分它们的 JSON 类型。只有数据约束保证相关前提时，改写才等价。应用应通过数据库驱动绑定参数，而不是把不可信输入拼接进 SQL 或 JSON 字符串；索引选择和输入处理需要分别正确。

操作符类也决定能力边界。jsonb_path_ops 支持包含以及适用的路径匹配，但不支持 jsonb_ops 提供的键存在算子。对合适数据，它可能更小、选择性更好，却不是无条件更优的替代品。同样，嵌套表达式索引必须对应实际使用的表达式，给完整文档建索引，并不意味着提取后的每棵子树都自动有独立索引。

缺失和空值是不同问题

键不存在、键对应 JSON null、键对应字符串“null”，是三种状态。存在判断会把后两种都视为存在。用 -> 提取 JSON 时，缺失键得到 SQL NULL，显式 null 得到 JSON null 值。用 ->> 提取文本时，缺失与 JSON null 都变成 SQL NULL，而字符串仍保留为文本。这些差别会影响过滤、唯一性假设和应用默认值。

如果业务关心键是否出现，应使用键存在检查；如果字段必须是字符串或数字，还要检查 JSON 类型。用普通等号和 NULL 比较，不能表达“键不存在”。另外，? 只检查顶层，不会递归查找文档任意深度的同名键。查询内部对象时，必须明确路径及对应索引，不能因某处存在同名键就认为顶层条件成立。

坏掉的样子

常见性能问题是建了 GIN，却保留不兼容的文本提取条件。另一个错误是认为索引只要适用，就一定会被选择。统计信息、选择性、表大小和成本估计都会影响计划；读取大部分数据时，顺序扫描可能合理。应先比较估计行数与实际行数，再判断问题是估计偏差、条件不匹配，还是索引本身收益不足。

大型灵活文档也会增加写入工作。GIN 要维护许多条目，更新文档依然是更新一行，会付出相应的锁和存储成本。应围绕真实负载的问题建立索引，不要为假想查询覆盖整篇文档。JSONB 语法合法，也不能证明必要业务字段存在或类型正确；这些要求要由实际契约和校验承担。新增 CHECK 时还要记住，表达式结果为 SQL NULL 也会通过检查；应明确要求键存在及类型正确，不能仅依赖可能返回空值的文本提取条件。

快速验证

把下面内容保存为 json-query.sql，在可丢弃的 PostgreSQL 18 数据库中执行 psql -X -v ON_ERROR_STOP=1 -f json-query.sql。实验在事务中创建临时数据，末尾回滚清除。其中只有百分之一的行处于 pending 状态，便于观察选择性较高时的计划。

\set ON_ERROR_STOP on
BEGIN;
CREATE TEMP TABLE documents (id integer, payload jsonb NOT NULL);
INSERT INTO documents SELECT g, jsonb_build_object('status',
 CASE WHEN g%100=0 THEN 'pending' ELSE 'done' END)
FROM generate_series(1,10000) AS g;
CREATE INDEX documents_payload ON documents USING gin(payload);
ANALYZE documents;
EXPLAIN (ANALYZE, BUFFERS, TIMING OFF)
SELECT id FROM documents WHERE payload @> '{"status":"pending"}';
EXPLAIN (COSTS OFF)
SELECT id FROM documents WHERE payload->>'status'='pending';
CREATE INDEX documents_status ON documents ((payload->>'status'));
ANALYZE documents;
EXPLAIN (COSTS OFF)
SELECT id FROM documents WHERE payload->>'status'='pending';
SELECT value, value ? 'x' AS has_key,
 value->'x' IS NULL AS sql_null_json, value->>'x' IS NULL AS sql_null_text
FROM (VALUES ('{}'::jsonb),('{"x":null}'::jsonb),('{"x":"null"}'::jsonb)) v(value);
DO $$ BEGIN
 IF (SELECT count(*) FROM documents WHERE payload @> '{"status":"pending"}') <> 100 THEN
 RAISE EXCEPTION 'wrong containment count';
 END IF;
 IF '{"n":1}'::jsonb @> '{"n":"1"}'::jsonb THEN
 RAISE EXCEPTION 'number and string were conflated';
 END IF;
 IF '{"outer":{"x":1}}'::jsonb ? 'x' THEN
 RAISE EXCEPTION 'top-level existence searched recursively';
 END IF;
 IF ('{"x":null}'::jsonb->'x') IS NULL THEN
 RAISE EXCEPTION 'JSON null confused with missing key';
 END IF;
END $$;
ROLLBACK;

PostgreSQL 18.6 实测中，包含查询通过 documents_payload 使用位图索引扫描，返回一百行。文本提取条件最初使用顺序扫描，创建表达式索引后改用 documents_status。这些是当前分布下观察到的选择，并不是固定的计划承诺，也不能用来估计生产延迟。迁移到其他规模或数据形态后，需要重新检查实际计划。

最后三行分别展示缺失、显式 JSON null 和文本字符串。它们的存在标记依次为假、真、真；文本提取结果是否为 SQL NULL 的标记依次为真、真、假。断言还验证包含判断区分类型，键存在检查不会递归。修改查询形态时，应保留这些语义检查：只有结果仍符合预期，计划变快才有价值，不能用一个更快但混淆空值或类型的条件替代原有业务含义。

来源

PostgreSQL JSON 类型与索引，GIN 操作符类与表达式索引，已核验 2026-10-15。
PostgreSQL JSON 函数与操作符，提取、存在、包含和空值语义，已核验 2026-10-15。
PostgreSQL 18: CHECK 约束的空值行为，CHECK 接受未知结果及显式空值约束，已核验 2026-10-15。

Postgres 索引的存在意义就是回答问题

Tue, 20 Jul 2027 00:00:00 +0000

索引的价值在于改变真实查询需要完成的工作，索引了多少列并不是有效的成功指标。一个能直接找到某位客户最新三笔订单的窄 B-tree，可能胜过无法提供所需顺序的宽索引；读取几乎全部行的查询，则可能正确地忽略两者。评估时要把访问方式、排序和返回数据量放在一起，而不是看到索引名称就宣布优化完成。

从需要的结果出发

假设应用要查询某位客户最新三笔订单。customer 的等值条件缩小候选范围，placed_at 降序选择该客户最新记录，再用 id 作为最后决胜键，处理时间戳相同的情况。(customer, placed_at DESC, id DESC) 就表达了这条查询需要的键顺序。每个键都应对应可解释的条件或排序要求，而不是根据列名凭直觉添加。

收益不只是避免全表扫描。有序索引路径可以取得所需的有限结果后就停止，不必先收集该客户全部订单再排序。去掉 LIMIT，或改成返回大部分行后，成本平衡可能变化。因此同一个索引必须结合完整 SQL 和常用参数评价，不能只盯 WHERE 的一个片段，更不能把少量结果的计划当成大规模导出的保证。

WHERE 条件的文本顺序不会定义索引顺序。PostgreSQL 规划逻辑表达式，把 customer 等值写在 AND 前面或后面，不会重排 B-tree。真正相关的是索引方向、空值顺序、前导键限制和最终 ORDER BY。修改查询时应明确核对这些结构属性，而不是套用“列写在前面就能用索引”的笼统规则。PostgreSQL 18 还能在缺失前导键的不同值较少时，对某些后续键条件采用 B-tree skip scan；没有前导等值条件，并非绝对禁止使用索引。

如实读取执行计划

EXPLAIN 展示计划工作，EXPLAIN ANALYZE 会真正执行并报告实际行数和循环次数。查询返回表中大部分数据，尤其需要索引中没有的宽列时，顺序扫描可能是正确选择。这不证明列顺序错误，也不证明索引创建失败。应把它看成优化器在当前条件下选择的访问成本，而不是必须消除的红色标记。

反过来，出现索引名也不证明查询便宜。索引扫描仍可能访问大量条目和堆元组，bitmap 路径可能还要排序，index-only 计划也可能检查堆可见性。结合 actual rows、适用时的 Heap Fetches、缓冲区活动和 Sort 阅读。顶层有 LIMIT 只有在下层也避免了大量多余工作时才真正省事，不能忽略 LIMIT 下面的完整树。

坏掉的样子

生产参数可能比开发参数多选出几千倍的行。小客户上表现优秀的索引，对拥有大量订单的大客户未必同样合算。数据分布、统计信息、缓存和并发都会影响计划与延迟，验证变更时应保留多个代表性参数。只测试一个常见编号，很容易遗漏真正拖慢系统的极端但合法客户。

索引还会持续产生存储、缓存、写入维护和构建成本。仅因为一次诊断查询返回 note，就把宽 note 加入热索引，可能让日常写入更贵。应该区分窄的高频应用查找和偶尔的大范围报表，要求每个附加键或 INCLUDE 列都有反复出现的真实用途。不能用读路径的一次局部收益掩盖整个系统长期承担的维护工作。

还有一种问题是分页依赖未定义的顺序。时间戳相同或执行计划改变时，如果 ORDER BY 没有给出确定选择，前几条记录可能变化。索引本身不会独立建立 API 的排序契约。顺序应明确写在 SQL 中，测试也应检查具体标识，而不只是检查“返回了三行”，否则拿错三行仍可能通过表面的数量校验。

快速验证

保存为 topn.sql，运行 psql -X -v ON_ERROR_STOP=1 -f topn.sql，连接可丢弃的 PostgreSQL 18 数据库。夹具创建两万笔订单，分布在一百位客户中，并加入一个较宽的 note 列用于比较全量查询。表和索引都是临时对象，最后回滚清理，不依赖业务数据。

\set ON_ERROR_STOP on
BEGIN;
CREATE TEMP TABLE orders (id integer, customer integer, placed_at integer, note text);
INSERT INTO orders SELECT g, g%100, g, repeat('x',100) FROM generate_series(1,20000) AS g;
CREATE INDEX orders_customer_recent ON orders (customer, placed_at DESC, id DESC);
ANALYZE orders;
EXPLAIN (ANALYZE, BUFFERS, TIMING OFF)
SELECT id,placed_at FROM orders WHERE customer=7 ORDER BY placed_at DESC,id DESC LIMIT 3;
EXPLAIN (ANALYZE, BUFFERS, TIMING OFF)
SELECT * FROM orders WHERE customer>=0;
SELECT array_agg(id ORDER BY placed_at DESC,id DESC) AS newest
FROM (SELECT id,placed_at FROM orders WHERE customer=7
 ORDER BY placed_at DESC,id DESC LIMIT 3) s;
DO $$ BEGIN
 IF (SELECT array_agg(id ORDER BY placed_at DESC,id DESC)
 FROM (SELECT id,placed_at FROM orders WHERE customer=7
 ORDER BY placed_at DESC,id DESC LIMIT 3) s)
 IS DISTINCT FROM ARRAY[19907,19807,19707] THEN
 RAISE EXCEPTION 'wrong newest orders';
 END IF;
END $$;
ROLLBACK;

客户七的结果按顺序是 19907,19807,19707。PostgreSQL 18.6 选择 Limit 加 index-only scan，找到三条匹配行后停止；因为新表尚未 VACUUM，仍需要堆可见性检查。查询所有客户并返回 note 时，计划选择顺序扫描，实际返回两万行。两种选择分别对应各自的任务，并不互相矛盾，也不说明某个索引突然失效。

断言检查确定的前三条结果，耗时和缓冲区数字不被写成固定预期。这个实验展示按工作负载使用索引，不提供跨机器速度倍数，也不保证生产数据与需求变化后同一计划永远最优。若未来增加全局排序、额外过滤或更多返回列，就应重新检查完整语句的访问路径和成本。

来源

PostgreSQL 多列索引，键条件与扫描范围，已核验 2026-10-15。
PostgreSQL 索引与 ORDER BY，有序读取与 LIMIT，已核验 2026-10-15。
PostgreSQL 使用 EXPLAIN，理解计划中的实际工作，已核验 2026-10-15。

函数索引把值在写入时预先算好

Wed, 05 May 2027 00:00:00 +0000

表达式索引把计算结果保存为索引键。查询比较 lower(email) 时，可以搜索预先计算的键，而不用对整张表逐行执行 lower。代价是索引创建和维护阶段需要完成计算与存储。它不会修改原始 email，也不保证任何查询都会选择这个索引，更不意味着表达式文本有一点不同就必然失去匹配。

索引计算后的含义

lower(email) 索引保存的是与行关联的规范化结果，使用相同计算含义的等值条件可以成为索引条件。直接比较原始 email 的语义不同，不会自动获得这条搜索路径。同样，先 trim 再 lower 增加了一项操作，现有索引不能假定去除空白永远不会改变数据。因此是否匹配要看计算本身，而不是只看它们都涉及 email 列。

PostgreSQL 匹配解析后的表达式，并进行某些简化。多加几层括号本身不会破坏匹配，因此查询不需要与索引定义逐字完全相同。反过来，数学上等价的写法也不一定都能被识别为相同。应检查计划中的实际条件和索引表达式定义，不能只做表面字符串比较，也不能承诺规划器能够证明任意表达式等价。

唯一表达式索引还能执行大小写规范化后的唯一性规则。这是在改变允许存储的数据，不只是提速。已有行规范化后发生冲突，会阻止索引创建；未来插入也会面对新约束。单纯 lower 不是邮箱等价性的完整定义，其他文本还可能受 locale 和 collation 影响。应先明确业务规范化规则，再决定把哪一种计算结果作为约束依据。

让被索引的值保持稳定

索引表达式中的函数必须满足 PostgreSQL 的不可变性要求：结果应依赖输入参数，而不能随着当前时间或外部状态自行变化。now() 不能被当成永远稳定的计算值建索引。为了绕过检查而把函数随意标为 IMMUTABLE，并不会让函数真的不可变，反而可能使已存索引键与后续计算结果不一致，产生比慢查询更严重的正确性问题。

表达式在插入及需要维护索引的更新时计算。即使规划器从不选它，存储和维护成本仍然存在。修改自定义函数行为或规范化策略时，也必须考虑已经保存在索引里的旧结果；仅替换函数代码不会重新计算所有键。重建索引和验证已有数据，应当属于这次语义变更的一部分，而不是上线后发现异常才补做。

坏掉的样子

ORM 重构可能把条件改成 lower(trim(email))，索引却仍保存 lower(email)。查询结果仍正确，但执行器可能扫描更多行。另一种问题是排序规则或自定义函数改变后，代码仍依赖旧键。排查时要对照最终生成的 SQL、索引定义、相关函数行为与目标环境，不能仅根据源代码中的一个方法名推断数据库收到什么。

把唯一表达式索引当成无害的性能调整也很危险。已有规范化重复值会让创建失败，未来写入则受到新的唯一约束。应审计并按业务语义处理冲突，不能为了建索引悄悄删除记录。生产创建还需要选择合适的方式并验证完整结束；目录里存在一个索引名称，不足以证明它已经成功构建并可用，失败的并发构建可能留下需要处理的状态。

快速验证

保存为 expression.sql，执行 psql -X -v ON_ERROR_STOP=1 -f expression.sql，连接可丢弃的 PostgreSQL 18 数据库。实验的一万个地址使用保留的 example.test 域名，表和索引都是临时对象，不会接触真实账户。异常块用于检查错误边界，而不只是展示一条成功查询。

\set ON_ERROR_STOP on
BEGIN;
CREATE TEMP TABLE accounts (id integer, email text NOT NULL);
INSERT INTO accounts SELECT g, 'User'||g||'@example.test' FROM generate_series(1,10000) AS g;
CREATE UNIQUE INDEX account_email_folded ON accounts (lower(email));
ANALYZE accounts;
EXPLAIN (ANALYZE, BUFFERS, TIMING OFF)
SELECT id FROM accounts WHERE ((lower(email)))='user42@example.test';
EXPLAIN (COSTS OFF)
SELECT id FROM accounts WHERE lower(trim(email))='user42@example.test';
DO $$ BEGIN
 INSERT INTO accounts VALUES (10001,'USER42@example.test');
 RAISE EXCEPTION 'case-folded duplicate accepted';
EXCEPTION WHEN unique_violation THEN RAISE NOTICE 'folded duplicate rejected';
END $$;
DO $$ BEGIN
 EXECUTE 'CREATE INDEX invalid_clock ON accounts ((now()))';
 RAISE EXCEPTION 'non-immutable index expression accepted';
EXCEPTION WHEN invalid_object_definition THEN RAISE NOTICE 'non-immutable expression rejected';
END $$;
DO $$ BEGIN
 IF (SELECT id FROM accounts WHERE lower(email)='user42@example.test') IS DISTINCT FROM 42 THEN
 RAISE EXCEPTION 'expression lookup failed';
 END IF;
END $$;
ROLLBACK;

PostgreSQL 18.6 在 lower(email) 外多加括号时仍使用 account_email_folded，增加 trim 的版本则采用顺序扫描。插入四十二号用户邮箱的大写重复形式，被唯一表达式索引拒绝；尝试给 now() 建索引，也因不可变性要求失败。最后的断言确认受支持的查找仍返回编号四十二，避免只观察错误消息而忘记正向行为。

异常处理只捕获预期数据库错误，本应失败却意外成功时脚本会报错。回滚清理全部实验对象。这些结果把无害语法变化与计算含义变化区分开，但没有覆盖全部 Unicode 规范化、所有排序规则、生产建索引锁行为或任意表达式等价性。那些结论需要各自的真实数据和具体操作，不能从这个小夹具直接推导。

来源

PostgreSQL 表达式索引，存储计算结果与唯一表达式，已核验 2026-10-15。
PostgreSQL CREATE INDEX，不可变性与构建要求，已核验 2026-10-15。

部分索引只保存真正需要的那些行

Tue, 27 Apr 2027 00:00:00 +0000

部分索引可以把高频访问的少量行放在更小的结构中。假如 open 任务很少，而请求多数只找 open 任务，在 id 上建立 WHERE status = 'open' 的索引就值得评估。但它是否可用，取决于规划器能为当前查询证明什么，不只是应用在某次执行时碰巧传入了 open。准备语句的计划方式会直接影响这份证据。

证明不需要被排除的行

索引里没有 closed 任务，因此不能独立回答可能需要 closed 行的查询。PostgreSQL 必须在规划时识别查询条件蕴含索引谓词。显式写出的 status = 'open' 提供了这个事实；通用计划中的 status = $1 则没有，因为同一份计划还必须在参数为 closed 时保持正确。规划器不能依靠应用的口头约定丢弃可能需要的数据。

蕴含关系不总是逐字相同。PostgreSQL 能识别一些简单逻辑关系，但不是任意表达式的定理证明器。统一真实需要的谓词，有助于避免重构把原本可用的索引条件藏起来。仅过滤索引键 id 也不能证明状态为 open，即使当前数据或业务习惯让它经常如此。性能优化必须保持查询语义，不能把偶然数据状态当成永久约束。

准备计划改变可用信息

准备语句可以使用根据具体参数规划的 custom plan，也可以使用跨参数复用的 generic plan。状态参数为 open 时，定制计划可能知道所需谓词并考虑部分索引；通用计划面对未知状态，就不能把该索引当成完整答案路径。SQL 文本没有变化，改变的是规划阶段掌握的信息，这也是同一语句不同执行阶段出现不同计划的原因之一。

这不代表参数化查询都无法使用部分索引。如果 status 始终显式为 open，只有 id 是参数，通用计划仍保留必要谓词。也不应为了追求索引把参数绑定换成字符串拼接；不可信输入仍应作为参数传递。正确做法是让查询表达真实不变量，而不是牺牲数据处理安全来获得一次漂亮的计划截图。

默认策略会依据成本考虑选择定制或通用计划。诊断时可以在会话中用 plan_cache_mode 强制两种行为进行比较，但这只是实验，不是要求全局关闭通用计划。重新规划也有成本，参数分布与执行频率都会影响取舍。应观察真实连接与实际重复执行，而不是把某次本地设置直接推广到整个系统。

坏掉的样子

一条查询可能在多次准备执行后变慢，因为可复用计划取代了依赖参数的计划，现象看起来像索引随机消失。应捕获应用真正发送的准备语句，并用代表性参数检查 EXPLAIN EXECUTE。临时把参数写成字面量的查询，不能复现所有准备计划条件。把谓词、计划模式、估计行数和实际工作量放在一起，才能定位差异来自哪里。

子集本身也可能不再小。任务积压使大多数记录都处于 open 时，原来的尺寸优势就会下降，而状态转换仍需要维护索引。不能仅根据建索引时的数据比例，就承诺以后写入更快、缓存更热。统计信息和接近生产的数据分布是评估前提，部分索引是一项工作负载选择，不会保证未来数据一直满足最初假设。

谓词限制的是索引条目，不是表里允许保存的行，也不是读取权限。closed 任务仍在表中，可以通过其他访问路径读取。若使用部分唯一索引，它也只约束满足谓词的子集，不能代替全局唯一性规则。审阅模型时，应把查询加速、数据完整性和访问权限分开，否则容易把物理结构误认为业务规则已经得到保证。

快速验证

把 SQL 保存为 partial-plan.sql，运行 psql -X -v ON_ERROR_STOP=1 -f partial-plan.sql，连接可丢弃的 PostgreSQL 18 数据库。临时表一万行中只有一百条 open，索引只保存这一子集；两条准备语句分别演示状态也是参数和状态固定两种真实不同的契约。

\set ON_ERROR_STOP on
BEGIN;
CREATE TEMP TABLE jobs (id integer, status text NOT NULL);
INSERT INTO jobs SELECT g, CASE WHEN g<=100 THEN 'open' ELSE 'closed' END
FROM generate_series(1,10000) AS g;
CREATE INDEX jobs_open_id ON jobs (id) WHERE status='open';
ANALYZE jobs;
PREPARE chosen(text,integer) AS SELECT id FROM jobs WHERE status=$1 AND id=$2;
SET LOCAL plan_cache_mode=force_generic_plan;
EXPLAIN (COSTS OFF) EXECUTE chosen('open',7);
EXECUTE chosen('open',7);
SET LOCAL plan_cache_mode=force_custom_plan;
EXPLAIN (COSTS OFF) EXECUTE chosen('open',7);
EXECUTE chosen('open',7);
PREPARE always_open(integer) AS SELECT id FROM jobs WHERE status='open' AND id=$1;
SET LOCAL plan_cache_mode=force_generic_plan;
EXPLAIN (COSTS OFF) EXECUTE always_open(7);
EXECUTE always_open(7);
DEALLOCATE chosen;
DEALLOCATE always_open;
ROLLBACK;

本轮 PostgreSQL 18.6 单用户 SQL 重跑中，状态未知的通用计划使用顺序扫描；未执行 psql 客户端与连接池行为。同一准备语句在强制定制计划、参数为 open 时使用 jobs_open_id。第二条语句把状态固定为字面量，只参数化 id，即使强制通用计划也使用该部分索引。三次执行都返回编号七，结果语义相同，访问路径却不同，体现的是规划信息差异而不是数据错误。

这些计划说明已知谓词的重要性，不承诺每台机器都选择完全相同的访问路径。SET LOCAL 的改变在回滚后结束，DEALLOCATE 清理准备语句，临时表也随事务撤销。实验并没有复现真实连接池中的自动计划切换；那需要记录应用会话、参数分布与重复执行历史，不能用强制模式的结果冒充已验证线上触发条件。

来源

PostgreSQL 部分索引，规划阶段的谓词蕴含关系，已核验 2026-10-15。
PostgreSQL PREPARE，定制与通用执行计划，已核验 2026-10-15。

按所需操作选择 B-tree 或哈希索引

Sun, 07 Feb 2027 00:00:00 +0000

PostgreSQL 默认的 B-tree 索引支持多种常见需求，包括等值、范围、有序访问和唯一性约束；哈希索引提供的则是更窄的等值访问路径。两者的选择应先从需要支持的运算符与数据约束开始，再进入性能测量。说哈希“只要是等值就一定更快”，或者规划器“几乎从来不会选它”，都是用未经负载验证的概括代替具体问题。先确认能力，再比较成本，顺序不能颠倒。

先检查能力，再比较耗时

B-tree 按运算符类和排序规则保留键的顺序，因此既能定位单个等值键，也可能支持有界范围与 ORDER BY，省掉额外排序。它还可以为 IS NULL 和 IS NOT NULL 提供索引访问。不过，存在索引不等于强制使用索引；查询需要读取很大一部分表时，规划器仍可能选择其他路径。这并不改变索引在语义上支持哪些操作。

文本模式另有条件。像 LIKE 'abc%' 这样由常量构成、锚定开头的前缀，可以利用合适的 B-tree 路径，但排序规则和运算符类会影响适用性。非 C 区域设置下，可能需要专门支持模式匹配的运算符类。开头带通配符的匹配，也不会因为创建了普通 B-tree 就自动变成高选择性的有序范围。不能把“支持部分前缀匹配”写成“所有 LIKE 都能一趟索引解决”。

PostgreSQL 哈希索引保存四字节哈希码，而不是完整列值。它支持等值，不保留键顺序，只支持单个索引列，也不能检查唯一性。对于较大值，较小的索引条目可能有利于某些等值负载，但读取堆记录进行复核、访问桶和溢出页仍有成本。数据结构的名字本身不能证明某次真实查询谁会胜出。

坏掉的样子

把 B-tree 换成哈希索引，可能失去原有的范围或有序访问路径，也会失去 IS NULL 的索引访问能力：PostgreSQL 哈希索引不支持这个条件。更严重的是，把承担唯一性要求的索引替换成哈希索引，因为后者根本无法提供对应约束。即使点查偶尔更快，也不能用性能收益替代数据完整性契约。

空值语义需要单独核对。默认唯一 B-tree 允许多个空值，因为唯一性检查把它们视为彼此不同。如果应用要求最多只能出现一个空值，应在唯一约束或索引上明确使用 NULLS NOT DISTINCT，而不能从“唯一”两个字直接推导。索引支持怎样访问，与它强制哪些数据规则，是关联但不同的两项决定。验证时必须分别看查询结果和约束行为。

快速验证

在 PostgreSQL 18 的 psql 中运行下面实验。临时表含两万个整数键和两条键为空的记录，先建立哈希索引，再把它替换为唯一 B-tree。整个实验在事务内运行，最后回滚清理。

\set ON_ERROR_STOP on
BEGIN;
CREATE TEMP TABLE points (key integer,value text);
INSERT INTO points SELECT g,'value-'||g FROM generate_series(1,20000) AS g;
INSERT INTO points VALUES (NULL,'no-key-a'),(NULL,'no-key-b');
CREATE INDEX points_hash ON points USING hash(key);
ANALYZE points;
EXPLAIN (ANALYZE, BUFFERS, TIMING OFF) SELECT value FROM points WHERE key=12345;
EXPLAIN (ANALYZE, BUFFERS, TIMING OFF)
SELECT key,value FROM points WHERE key>=12340 AND key<12350 ORDER BY key;
EXPLAIN (ANALYZE, BUFFERS, TIMING OFF) SELECT value FROM points WHERE key IS NULL;
DO $$ BEGIN
 CREATE UNIQUE INDEX points_hash_unique ON points USING hash(key);
 RAISE EXCEPTION 'hash uniqueness unexpectedly supported';
EXCEPTION WHEN feature_not_supported THEN RAISE NOTICE 'hash cannot enforce uniqueness';
END $$;
DROP INDEX points_hash;
CREATE UNIQUE INDEX points_btree ON points(key);
EXPLAIN (ANALYZE, BUFFERS, TIMING OFF) SELECT value FROM points WHERE key=12345;
EXPLAIN (ANALYZE, BUFFERS, TIMING OFF)
SELECT key,value FROM points WHERE key>=12340 AND key<12350 ORDER BY key;
EXPLAIN (ANALYZE, BUFFERS, TIMING OFF) SELECT value FROM points WHERE key IS NULL;
DO $$ BEGIN
 IF (SELECT value FROM points WHERE key=12345) IS DISTINCT FROM 'value-12345' OR
 (SELECT count(*) FROM points WHERE key>=12340 AND key<12350) <> 10 OR
 (SELECT count(*) FROM points WHERE key IS NULL) <> 2 THEN RAISE EXCEPTION 'index changed answers'; END IF;
END $$;
ROLLBACK;

PostgreSQL 18.6 实测中，哈希等值查询使用 points_hash，返回 value-12345。十个键的范围查询采用顺序扫描加排序，空值查询也采用顺序扫描，返回两行。尝试建立唯一哈希索引时，数据库抛出预期的不支持特性异常，代码块有意捕获这一种失败；如果发生别的错误，脚本仍然停止，不能把任意失败都解释成验证成功。

替换后，本夹具中的 B-tree 支持了等值、有界有序范围和空值查找。范围结果仍是十行，空值结果仍是两行。尽管有两个空值，唯一索引仍然建立成功，恰好说明默认的空值彼此不同语义。断言检查访问路径变化没有改变答案，避免把计划用了索引与结果正确混为一谈。

计划选择与页面计数会随表大小、缓存、统计和配置变化。本实验建立的是能力边界及一次实际选择，不是证明所有机器上某种方法都更快的基准测试。相反，哈希不能实现唯一性这一点，不会因为数据量或成本参数改变而突然消失。可优化的成本与不可省略的契约应分别处理。

测量完整负载

真实候选应同时比较有代表性的等值查询、范围查询、排序要求、写入活动、存储和维护开销。在受控环境比较替代方案，避免随手在生产上建立多个很大的竞争索引。哈希索引可能凭某个经过测量的等值负载证明价值，而 B-tree 仍因唯一性或其他查询必须保留。每个留下的索引都应对应实际访问或完整性要求，并把写入成本与读取收益一起评估。

来源

PostgreSQL 18：索引类型，B-tree 与哈希索引支持的条件，已核验 2026-10-15。
PostgreSQL 18：哈希索引，碰撞复核与桶维护，已核验 2026-10-15。
PostgreSQL 18：约束，唯一性与空值语义，已核验 2026-10-15。

预备计划必须证明部分索引谓词

Sat, 17 Oct 2026 00:00:00 +0000

一个任务队列可能只有一百条待处理记录，却保留了成千上万条已完成记录。如果主要请求都是领取待处理任务，只为这个子集建立索引就可能更合适。PostgreSQL 把它称为部分索引，索引谓词决定哪些表行拥有条目。收益仍取决于真实查询和状态变化，不能把“所有索引越小越好”当成脱离业务的优化目标。

坏掉的样子

条件之间的蕴含方向不能写反：查询条件必须蕴含索引谓词，也就是查询可能需要的每一行都在索引覆盖范围内。只收录待处理任务的索引，不能完整回答没有状态限制的全表查询。两个条件看上去不矛盾，也不代表规划器能证明它们之间的关系。PostgreSQL 不会识别所有数学上等价的写法，所以让谓词接近应用实际过滤表达式，也有助于人工审阅和计划识别。

哪些参数已经知道，同样由计划阶段决定。预备语句的定制计划，可以使用这次传入的状态值；通用计划却必须对所有可能的参数都成立，不能假定每次调用永远查询待处理状态。因此，手工测试常量查询时看到索引被使用，并不能直接证明应用长期执行的预备语句也会选择同一条访问路径。

快速验证

在 PostgreSQL 18 的可丢弃数据库中，使用一个全新的 psql -X -v ON_ERROR_STOP=1 会话按顺序执行。实验没有建立覆盖全表的其他索引，便于观察资格差异。先创建一万条任务，其中编号为一百整数倍的记录处于待处理状态：

CREATE SCHEMA partial_demo;
CREATE TABLE partial_demo.jobs (id integer,state text);
INSERT INTO partial_demo.jobs
SELECT g,CASE WHEN g%100=0 THEN 'ready' ELSE 'done' END
FROM generate_series(1,10000) AS g;
CREATE INDEX ready_jobs ON partial_demo.jobs(id) WHERE state='ready';
VACUUM (ANALYZE) partial_demo.jobs;
SELECT state,count(*) FROM partial_demo.jobs GROUP BY state ORDER BY state;

分组结果应是已完成九千九百条、待处理一百条。这里索引键是任务编号，谓词检查的是状态，两者不要求是同一个字段。先检查带常量条件的计划：

EXPLAIN (ANALYZE,COSTS OFF,TIMING OFF,SUMMARY OFF,FORMAT JSON)
SELECT id FROM partial_demo.jobs WHERE state='ready' ORDER BY id LIMIT 5;

本次得到的计划在限制节点之下使用 ready_jobs 的仅索引扫描，返回五行。前面的清理建立了实验所需的可见性信息，使这次扫描能够避免访问堆页。部分索引本身并不保证仅索引扫描；查询所需列和可见性状态仍然重要。首先应核对的是索引名字、实际行数与结果，而不是只盯着某个扫描类型。

接着，把状态改成参数，并为比较而明确选择定制计划：

PREPARE next_jobs(text) AS
SELECT id FROM partial_demo.jobs WHERE state=$1 ORDER BY id LIMIT 5;
SET plan_cache_mode=force_custom_plan;

EXPLAIN (ANALYZE,COSTS OFF,TIMING OFF,SUMMARY OFF,FORMAT JSON)
EXECUTE next_jobs('ready');

此时计划仍然使用部分索引，因为规划时已经知道参数是待处理状态。保留同一条预备语句，切换到通用计划：

SET plan_cache_mode=force_generic_plan;

EXPLAIN (ANALYZE,COSTS OFF,TIMING OFF,SUMMARY OFF,FORMAT JSON)
EXECUTE next_jobs('ready');

通用计划扫描表、滤掉九千九百行，再把匹配编号排序后取前五行。它保留状态参数，不能使用只覆盖某个固定状态的索引来服务所有调用。这里强制两种模式，是为了隔离并观察机制差异，不是建议对所有生产连接强制使用某一种模式。真实选择还要考虑规划开销、执行分布和调用次数。

执行两个不同状态的参数值，然后让一条任务跨越索引谓词的边界：

EXECUTE next_jobs('ready');
EXECUTE next_jobs('done');
DEALLOCATE next_jobs;
RESET plan_cache_mode;
UPDATE partial_demo.jobs SET state='done' WHERE id=100;
SELECT id FROM partial_demo.jobs WHERE state='ready' ORDER BY id LIMIT 5;
SELECT count(*) FROM partial_demo.jobs WHERE state='ready';
DO $$ BEGIN
 IF (SELECT array_agg(id ORDER BY id) FROM
 (SELECT id FROM partial_demo.jobs WHERE state='ready' ORDER BY id LIMIT 5) AS q)
 IS DISTINCT FROM ARRAY[200,300,400,500,600] THEN
 RAISE EXCEPTION 'partial-index membership result mismatch';
 END IF;
END $$;
DROP SCHEMA partial_demo CASCADE;

待处理请求先返回一百、二百、三百、四百、五百；已完成请求返回一至五。把编号一百改成已完成后，前五条待处理任务变成二百至六百，间隔仍是一百，总数降到九十九。断言核对的是状态更新后索引成员关系对应的查询结果，不能只以更新语句没报错作为正确性证据。最后释放预备语句、恢复计划配置并删除实验数据。

结合完整工作负载评估

一行进入或离开谓词覆盖范围时，索引成员关系需要维护。未被收录的行也仍然需要普通表写入，不能宣称部分索引消除了所有写成本。应结合代表性的状态流转，观察索引体积、查询计划与维护代价。如果后来大多数任务都变成待处理，原先预期的优势可能减弱，顺序扫描也可能成为合理选择。

部分唯一索引只约束满足谓词的那些行，索引之外的记录不受这条唯一规则限制。这适合允许历史记录重复的某些模型，却不适合要求全局唯一的业务标识。另一个容易误用的边界是时间：谓词涉及的函数需要满足不可变要求，索引成员也不会仅因为时钟跨过午夜就自动重新分类。如果业务真正查询的是某个状态，应明确维护该状态，而不是用会随当前时间改变答案的条件来暗示索引会自行更新。

来源

PostgreSQL 18 部分索引，谓词蕴含关系及子集唯一性，已核验 2026-10-15。
PostgreSQL 18 CREATE INDEX，索引谓词及不可变表达式要求，已核验 2026-10-15。
PostgreSQL 18 PREPARE，预备语句的通用及定制计划与控制方式，已核验 2026-10-15。

索引 · XB 现场笔记

InnoDB 覆盖索引包含查询所需的列

坏掉的样子

快速验证

有意识地承担覆盖成本

来源

部分索引的写入成本

区分成员资格与更新成本

可以使用与值得使用是两回事

坏掉的样子

快速验证

来源

延伸阅读

哈希索引复核碰撞，也要维护变化的键

桶里究竟保存什么

坏掉的样子

快速验证

把维护也放进性能评估

来源

部分唯一性约束保护有效子集

成员资格随谓词变化

唯一性可以只针对子集

查询也要表达同一边界

坏掉的样子

快速验证

来源

覆盖索引有条件地避免堆访问

覆盖实际返回的列

可见性映射决定是否访问堆

坏掉的样子

快速验证

来源

小表上全表扫描可能更快

看清两条路径实际做什么

保留历史测量的适用范围

坏掉的样子

快速验证

来源

组合索引贴合多列的查询

排序的是键，不是 SQL 条件

后面的键仍可能有用

把排序和工作负载一起考虑

坏掉的样子

快速验证

来源

Postgres JSONB 搭配 GIN 做灵活查询

让算子与索引对应

缺失和空值是不同问题

坏掉的样子

快速验证

来源

Postgres 索引的存在意义就是回答问题

从需要的结果出发

如实读取执行计划

坏掉的样子

快速验证

来源

函数索引把值在写入时预先算好

索引计算后的含义

让被索引的值保持稳定

坏掉的样子

快速验证

来源

部分索引只保存真正需要的那些行

证明不需要被排除的行

准备计划改变可用信息

坏掉的样子

快速验证

来源

按所需操作选择 B-tree 或哈希索引

先检查能力，再比较耗时

坏掉的样子

快速验证

测量完整负载

来源

预备计划必须证明部分索引谓词

坏掉的样子

快速验证

结合完整工作负载评估

来源