南瑾i1. 项目概述与核心需求解析
1.1 为什么说索引是 PostgreSQL 性能调优的第一课
只要是接触过 PostgreSQL 一段时间的人，迟早都会碰到索引这个问题。数据量小的时候，全表扫描根本不是事儿，几千条记录怎么查都很快。但一旦表里的数据到了几十万、几百万甚至上亿的级别，一条不带索引的查询可能从毫秒级直接掉到秒级甚至分钟级，这时候索引就不再是可选项，而是必须项。
PostgreSQL 的索引体系其实非常丰富，B-Tree、Hash、GiST、SP-GiST、GIN、BRIN 都有各自的适用场景。但日常业务里，用得最多的还是 B-Tree 索引。而在 B-Tree 索引的实战中，唯一索引和复合索引又是两个绕不开的重点。这两个东西看似简单，实际用起来门道不少——什么时候该建唯一索引？复合索引的列顺序到底怎么排？为什么明明建了索引，查询还是不走？这些问题如果不搞清楚，索引反而可能成为负担。
这篇文章就是聚焦这两类索引，从原理到实操，从建索引到验证效果，把该踩的坑都提前告诉你。适合已经会写基础 SQL、知道 CREATE INDEX 是干嘛的，但想在索引这块更进一步的同学。如果你才刚开始接触 PostgreSQL，建议先把建表、插入、查询这些基本操作过一遍再回来看，体验会好很多。
1.2 唯一索引和复合索引分别解决什么问题
先一句话说清楚这两个东西。
唯一索引，核心是保证某一列（或某几列组合）的值在整张表里不重复。比如用户表的邮箱、订单表的订单号、库存表的商品编码，这些字段天然就不该有重复值。唯一索引除了提升查询速度，更重要的是从数据库层面兜底，防止业务代码里漏判导致脏数据。
复合索引，是同时对多个列建立索引。它的典型场景是查询条件里同时出现多个字段，比如 WHERE status = 'active' AND created_at > '2024-01-01'。如果只给 status 建索引，或者只给 created_at 建索引，查询时只能利用其中一个，另一个字段还得回表过滤。复合索引让两个条件都能在索引层面完成定位，效率自然高不少。
注意，复合索引不一定非要多个查询条件才用得上。有时候一个查询条件加一个排序字段，比如 WHERE user_id = 123 ORDER BY created_at DESC，这种场景建 (user_id, created_at) 的复合索引，既能定位 user_id，又能在索引内直接按顺序读取 created_at，省掉一次排序操作，收益同样很明显。
1.3 什么情况下才真正需要这两类索引
不是所有表都需要索引，更不是索引越多越好。我见过不少新手把能加的索引全加一遍，结果写入性能暴跌，查询也没快多少。判断是否需要索引，核心看两点：查询频率和数据量。
唯一索引的判断标准很简单——业务上这一列或列组合是否必须唯一。如果不允许重复，比如用户名、身份证号、手机号，那就建。就算当前数据量不大，也要建，因为你永远不知道什么时候业务量上来，脏数据就混进来了。
复合索引的判断标准相对灵活。先看慢查询日志或者 EXPLAIN ANALYZE 的输出，确认哪些查询经常出现、哪些查询耗时最长，再针对这些查询的 WHERE 条件、JOIN 条件、ORDER BY 字段来设计复合索引。不要凭空猜测，用数据说话。
数据量方面，一般表里几万条以内，索引的收益不明显；几十万条以上，索引就开始发挥作用了；到了百万、千万级别，没有索引的查询基本没法看。当然这个阈值跟服务器性能、查询复杂度都有关系，不是一个绝对值，但可以作为参考。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 核心原理：索引到底是怎么加速查询的
2.1 一张图理解 B-Tree 索引的物理结构
要真正用好索引，得先理解它的底层结构。PostgreSQL 默认的 B-Tree 索引，本质是一种平衡多叉树。想象一下图书馆的索引卡片柜：你要找一本叫《数据库原理》的书，不用一本一本翻书架，直接去索引卡片柜，按字母顺序找到"D"开头的卡片，卡片上写着书的位置，照着位置去拿书就行。B-Tree 索引就是这个卡片柜。
索引的行数据一般长这样：每一行索引记录由索引键值和对应的 ctid（行指针）组成。ctid 指向表里对应的物理行，格式是 (page_number, tuple_index)，比如 (0, 5) 表示第 0 页的第 5 行。查询时，先通过 B-Tree 快速定位到符合条件的索引键，拿到 ctid，再去表里取完整行数据，这个过程叫回表（Table Access by Index RowID）。
B-Tree 的树形结构让查找复杂度从全表扫描的 O(n) 降到了 O(log n)。也就是说，100 万条数据全表扫描平均要比较 50 万次，而 B-Tree 索引只需要大概 20 次比较就能定位到目标。这就是索引加速查询的根本原理，也是为什么索引能带来数量级性能提升的原因。
2.2 唯一索引的约束机制和数据一致性保障
唯一索引和普通索引的根本区别在于，它多了一层唯一性约束。创建唯一索引时，PostgreSQL 会扫描整个表，检查有没有重复值。如果存在重复，索引创建会直接失败，并报错告诉你哪些行重复了。这一点在实际操作中经常被忽略，后面我会详细讲。
唯一性约束的保证机制是：每次插入或更新数据时，PostgreSQL 会在索引中做一次唯一性检查。如果新值已经存在于索引中，就会返回 duplicate key value violates unique constraint 错误。这个检查发生在事务提交之前，但索引本身是在语句执行时更新的，所以并发场景下，PostgreSQL 通过索引的锁机制来保证并发插入时的唯一性。
有个容易忽略的细节：PostgreSQL 认为 NULL 和 NULL 是不相等的。也就是说，唯一索引不限制 NULL 值的重复。如果某一列允许为空，你可以插入多条该列为 NULL 的记录，唯一索引不会拦截。这个行为跟 Oracle 一致，但跟 MySQL（MySQL 唯一索引允许多个 NULL，但有的版本配置不同）不完全一样。业务上如果要求"除了 NULL 之外都唯一"，那只能用部分索引来解决，或者用 COALESCE 把 NULL 映射成特殊值。这块到后面实操部分我再展开。
2.3 复合索引的列顺序为什么这么关键
复合索引的原理要复杂一点。假设建了 (a, b) 复合索引，索引数据会先按 a 排序，a 相同的情况下再按 b 排序。这个排序规则决定了索引的可用性：
- 查询条件包含
a，可以用到这个索引 - 查询条件同时包含
a和b，也可以用这个索引 - 查询条件只包含
b，无法使用这个索引
这就是最常说的"最左前缀原则"。复合索引本质上是多级索引，只有用了前面的列，后面的列才能被用到。这个理解起来最直观的方式就是查字典：字典先按拼音首字母排，再按第二个字母排，第三个字母依此类推。你查"guo"这个字，如果只跟我说第三个字母是"o"，我根本没法帮你快速定位。
复合索引列顺序的选择策略，简单说就是：等值条件放前面，范围条件放后面。WHERE a = 1 AND b > 10，这种场景 (a, b) 的索引比 (b, a) 好，因为 a 等值能精确定位一条区间，b 的范围过滤在这个区间内进行，效率很高。如果反过来建 (b, a)，b 的范围条件无法高效定位，a 的等值条件也用不上，索引基本就废了。
另外一个常见策略是：把区分度高的列放前面。比如 (user_id, status) 和 (status, user_id)，假设 user_id 有 1 万个不同的值，status 只有 3 个不同的值，那 (user_id, status) 显然更合理，因为第一层就能把数据缩小到很少的范围。当然，这个原则要跟最左前缀原则配合使用，毕竟索引不是只看第一列的区分度，还要考虑查询条件本身能不能命中。
3. 实操准备：环境搭建与基础数据结构设计
3.1 准备一张有代表性的业务表
讲再多理论，不如动手建一张表实测一下。为了方便演示，我设计一个电商场景的订单表，这个表的字段覆盖了多种索引应用场景，后面所有例子都基于它来跑。
sql复制CREATE TABLE orders (
id BIGSERIAL PRIMARY KEY,
order_no VARCHAR(32) NOT NULL,
user_id BIGINT NOT NULL,
status SMALLINT NOT NULL DEFAULT 0,
amount NUMERIC(10, 2) NOT NULL DEFAULT 0,
created_at TIMESTAMP NOT NULL DEFAULT now(),
paid_at TIMESTAMP
);
这个表里：
order_no是订单号，业务上要求唯一，一会儿用唯一索引来约束user_id是用户 ID，查询订单时最常出现的条件status是订单状态，0 待付款、1 已付款、2 已发货、3 已完成、4 已取消，这个字段区分度很低，适合演示复合索引时列顺序的问题created_at是创建时间，适合做时间范围查询
先插入一批测试数据。这里我用 generate_series 生成 50 万条记录，数据量不算大，但足以看出索引带来的差异。
sql复制INSERT INTO orders (order_no, user_id, status, amount, created_at, paid_at)
SELECT
'ORD' || LPAD(g::text, 8, '0'),
(random() * 10000)::int + 1,
(random() * 4)::int,
(random() * 10000)::numeric(10, 2),
now() - (random() * 365 * 24 * 3600)::int * interval '1 second',
CASE WHEN random() > 0.3 THEN now() - (random() * 365 * 24 * 3600)::int * interval '1 second' ELSE NULL END
FROM generate_series(1, 500000) AS g;
注意 order_no 我用了 LPAD 补齐 8 位，这样数据看起来规整一些。user_id 随机生成 1 到 10000 之间的值，意味着平均每个用户有 50 条订单，这个分布比较符合真实业务。status 均匀分布在 0 到 4 之间，区分度确实不高。
3.2 建立索引前的基线查询表现
建索引之前，先跑几个查询，看看全表扫描的代价有多大。用 EXPLAIN ANALYZE 来观察执行计划，这是 PostgreSQL 性能分析最常用的工具。
sql复制EXPLAIN ANALYZE SELECT * FROM orders WHERE order_no = 'ORD00012345';
执行结果大致如下（不同机器性能不同，但趋势一致）：
code复制Seq Scan on orders (cost=0.00..9623.00 rows=1 width=56) (actual time=0.031..27.835 rows=1 loops=1)
Filter: ((order_no)::text = 'ORD00012345'::text)
Rows Removed by Filter: 499999
Planning Time: 0.052 ms
Execution Time: 27.867 ms
注意看 Seq Scan 这个关键字，表示全表扫描。一共扫了 50 万行，过滤掉 499999 行，实际返回 1 行。27 毫秒在数据量小的时候不算什么，但如果是 5000 万行，扫描时间会线性增长到 2.7 秒左右，这个延迟在线上业务里已经很不理想了。
再看一个复合条件的查询：
sql复制EXPLAIN ANALYZE SELECT * FROM orders WHERE user_id = 123 AND status = 1 AND created_at > now() - interval '30 days';
同样会是全表扫描。两个查询都说明：没有任何索引的情况下，PostgreSQL 只能硬着头皮扫全表。
3.3 确认当前表的索引状态
建索引之前，可以用下面的 SQL 查看当前表上已经有哪些索引：
sql复制SELECT
indexname,
indexdef
FROM pg_indexes
WHERE tablename = 'orders';
这条命令会列出 orders 表上所有已有的索引和创建它的完整语句。一般来说，建表时指定了主键，PostgreSQL 会自动为主键创建一个唯一索引，所以这张表应该已经有一个 orders_pkey 索引（针对 id 列）。后面我们建的索引，都用这条命令来验证是否创建成功。
4. 唯一索引实操：创建、验证与重复数据处理
4.1 创建唯一索引的三种方式
PostgreSQL 里创建唯一索引有几种写法，实际效果有细微差别，但都能达到唯一性约束的目的。
第一种写法是在建表时直接定义唯一约束：
sql复制ALTER TABLE orders ADD CONSTRAINT uk_orders_order_no UNIQUE (order_no);
这个语句会在 order_no 列上创建一个唯一索引，索引名默认跟约束名一致，也就是 uk_orders_order_no。如果列上已经存在重复数据，这个语句会执行失败。
第二种写法是用 CREATE UNIQUE INDEX：
sql复制CREATE UNIQUE INDEX uk_orders_order_no ON orders (order_no);
这种方式创建的也是唯一索引，但它不生成约束对象，仅仅是一个索引层面的唯一性限制。两者的区别在于：约束是标准的 SQL 规范，可以被 information_schema 识别，也能被其他数据库工具解析；而 CREATE UNIQUE INDEX 是 PostgreSQL 的扩展写法，只能通过 pg_indexes 查看。
第三种写法是在建表语句里直接带 UNIQUE 约束：
sql复制CREATE TABLE orders (
id BIGSERIAL PRIMARY KEY,
order_no VARCHAR(32) NOT NULL UNIQUE,
...
);
这种写法最简洁，但不够灵活，因为索引的命名和参数没法精细控制。
从实践角度，我推荐用第一种 ALTER TABLE ... ADD CONSTRAINT 的方式，因为约束语义更明确，其他开发者看到 uk_orders_order_no 这个名字就知道这是个唯一约束，而不是碰巧建了个唯一索引。另外，有些 ORM 工具和数据库迁移工具对约束的同步支持更好。
4.2 创建失败的场景：重复数据怎么处理
前面说了，创建唯一索引时如果列上已经存在重复数据，索引会创建失败。我实际操作中碰到过几次，解决思路明确。
先造个重复数据看看效果：
sql复制INSERT INTO orders (order_no, user_id, status, amount, created_at)
VALUES ('ORD00012345', 9999, 0, 100, now());
因为 ORD00012345 在插入基础数据时已经存在了，执行上面这条 INSERT 会立刻报错：
code复制ERROR: duplicate key value violates unique constraint "uk_orders_order_no"
DETAIL: Key (order_no)=(ORD00012345) already exists.
这说明唯一索引已经在兜底拦截了。但如果你是在建索引之前就存在重复数据，那会先在建索引这一步就失败，报错信息会告诉你具体哪几行重复了。
处理方式分三步。第一步，查出所有重复的 order_no 和它们的数量：
sql复制SELECT order_no, COUNT(*)
FROM orders
GROUP BY order_no
HAVING COUNT(*) > 1;
第二步，根据业务逻辑决定保留哪行。一般保留 id 最小的一行（比如最早创建的订单），删除其余的：
sql复制DELETE FROM orders
WHERE id NOT IN (
SELECT MIN(id)
FROM orders
GROUP BY order_no
);
第三步，重新执行创建唯一索引的语句，这时候应该能顺利通过。注意，这个删除操作是不可逆的，执行前务必确认业务影响，最好先备份数据。
提示：生产环境处理唯一索引重复数据，不要直接跑 DELETE。先备份表，然后在事务里操作，确认没问题了再提交。数据量大的表删除重复数据时也要注意锁表时间，建议分批删除。
4.3 唯一索引对写入性能的附加开销
唯一索引不是免费的，它带来查询加速和唯一性保证的同时，也会让写入变慢。原因很简单：每次 INSERT 或 UPDATE，PostgreSQL 都要去更新索引，并且检查唯一性约束；如果这个表上有多个索引，所有索引都要同步维护。
实测一下。先在一个没有唯一索引的表上做批量插入，再在带唯一索引的表上做同样操作，对比耗时就能看出差异。当然，这个开销在单条插入时感觉不明显，但在高并发写入场景下就会放大。
我做过一个简单测试：50 万条数据，有唯一索引的情况比没有唯一索引的情况，批量插入时间大概多了 10% 到 15%。这个比例在业务上是可以接受的，毕竟是拿一部分写入性能换数据一致性。真正需要警惕的是：一个表上建了七八个索引，写入性能下降会非常明显。所以索引不是越多越好，能用复合索引解决的需求，就不要拆成多个单列索引。
关于唯一索引还有一个值得注意的小技巧：如果业务上需要通过唯一索引来加速查询，但又不希望写入太慢，可以把唯一约束建立在区分度高但又不会频繁更新的列上，比如订单号、流水号。而像"用户状态"这种经常变化的列，就不适合做唯一索引。
5. 复合索引实操：设计、创建与效果验证
5.1 第一步：针对实际查询设计复合索引的列顺序
现在回到我们的 orders 表。假设有一个高频查询场景：查看某个用户在最近一段时间内的已付款订单。这个查询的 WHERE 条件会同时包含 user_id、status 和 created_at。
先说结论：(user_id, status, created_at) 这个列顺序是最合理的。为什么？
user_id是等值条件，区分度高，放第一位。第一层就能把 50 万行缩小到某个用户的那几十条记录。status也是等值条件，但区分度低，只有 5 个不同值。它放在第二位没问题，因为user_id已经帮我们缩窄了范围，status的过滤只是在这个小范围内进行。created_at是范围条件，放最后。B-Tree 索引对范围条件的支持是"定位到起点后顺序扫描"，如果它前面还有等值条件，这种顺序扫描的效率非常高。
如果列顺序调换，比如建 (status, user_id, created_at)，由于 status 区分度太低，索引第一层就会分出大量重复分支，虽然也能用，但查询时扫描的索引节点会多不少。再比如建 (created_at, user_id, status)，如果查询条件里 created_at 是范围条件，那它后面的列在定位时几乎派不上用场，因为一旦进入范围扫描，索引就会退化为顺序遍历，无法利用后面列的等值条件快速收敛。
设计复合索引时，可以参考一条经验法则：
| 场景 | 推荐列顺序 | 原因 |
|---|---|---|
| 等值 + 等值 | 区分度高者优先 | 第一层缩小范围最大 |
| 等值 + 范围 | 等值列在前，范围列在后 | 等值定位后范围扫描效率最高 |
| 等值 + 排序 | 等值列在前，排序列在后 | 索引内天然有序，省去排序 |
| 多等值条件 | 区分度从高到低 | 层层缩小范围 |
这套法则不是绝对真理，但覆盖了绝大多数业务场景。真正复杂的场景还是要靠 EXPLAIN ANALYZE 实测对比。
5.2 第二步：创建复合索引的完整 SQL 示例
确定好列顺序，创建复合索引就很简单了。在开始之前，需要先把刚才演示用的重复数据清理掉（如果有的话），确保表没有被唯一索引搞挂。
sql复制CREATE INDEX idx_orders_user_status_time
ON orders (user_id, status, created_at DESC);
注意最后这个 DESC。为什么要单独指定排序方向？因为我们的业务查询里有 ORDER BY created_at DESC，也就是查看最近的订单排在前面。如果索引的排序方向跟查询的排序方向一致，PostgreSQL 可以直接按索引顺序读取，不用额外排序；如果不一致，就需要在读取后对结果做一次反向排序，多花一点代价。
对于 B-Tree 索引，PostgreSQL 支持反向扫描（Backward Scan），所以在索引列顺序不错的情况下，即使没有 DESC 也能正常工作，只是扫描方向不同。但显式指定 DESC 可以让优化器更容易选择索引而不是排序。在某些场景下（特别是分页查询），还能避免额外的排序开销。
如果你在这张表上还有很多其他查询模式，比如只按 user_id 查询、按 status 查询，那么 (user_id, status, created_at) 这个复合索引也能覆盖 WHERE user_id = ? 这个单条件查询，因为最左前缀原则保证了第一个列 user_id 能独立使用这个索引。但注意：它无法覆盖单独用 status 查询的场景，因为 status 不是最左列。
5.3 第三步：用 EXPLAIN ANALYZE 验证索引是否生效
索引创建完之后，重新执行之前的查询，验证执行计划是否真的走了索引。
sql复制EXPLAIN ANALYZE
SELECT * FROM orders
WHERE user_id = 123
AND status = 1
AND created_at > now() - interval '30 days';
执行计划大致如下：
code复制Index Scan using idx_orders_user_status_time on orders
(cost=0.43..12.51 rows=39 width=56)
(actual time=0.021..0.052 rows=28 loops=1)
Index Cond: ((user_id = 123) AND (status = 1) AND (created_at > (now() - '30 days'::interval)))
Planning Time: 0.085 ms
Execution Time: 0.058 ms
看几个关键信息：
Index Scan using idx_orders_user_status_time：说明索引真的被用上了。Index Cond：列出了在索引层面过滤的条件，三个条件全部命中。- 执行时间从之前的全表扫描 27 毫秒降到 0.058 毫秒，提升了差不多 480 倍。
这个提升在数据量只有 50 万时就已经很夸张了，到了千万级数据量，差距会呈指数级放大。这就是为什么索引在 OLTP 场景里是最刚需的性能调优手段。
再验证一下只按 user_id 查询时，复合索引能不能命中：
sql复制EXPLAIN ANALYZE
SELECT * FROM orders
WHERE user_id = 123;
执行计划应该是 Index Scan using idx_orders_user_status_time，说明最左前缀原则下，第一个列 user_id 确实能独立使用复合索引。但如果你直接查询 status：
sql复制EXPLAIN ANALYZE
SELECT * FROM orders
WHERE status = 1;
这会退化为全表扫描，因为 status 不在复合索引的最左列，无法使用这个索引。如果你经常写这样的查询，就得单独为 status 建一个单列索引，或者考虑调整复合索引的列顺序（但这会影响前面那个查询，所以需要综合权衡）。
5.4 部分索引（Partial Index）的补充玩法
复合索引的高阶话题，还有一个部分索引（Partial Index）值得提一嘴。部分索引就是在创建索引时加一个 WHERE 条件，只对满足条件的行建索引。它特别适合处理"大部分查询都只关心某一部分数据"的场景。
比如，我们的订单表里大部分查询都只看 status = 0（待付款）或者 status = 1（已付款）的订单，很少查已取消的。那就可以建部分索引：
sql复制CREATE INDEX idx_orders_user_status_paid
ON orders (user_id, created_at DESC)
WHERE status IN (1, 2, 3);
这样索引只在 status 为 1、2、3 的行上建立，索引体积更小，维护成本更低，查询速度也更快。唯一索引同样支持部分索引的玩法，比如之前提到的"除了 NULL 之外都唯一"的场景，就可以用部分唯一索引：
sql复制CREATE UNIQUE INDEX uk_orders_order_no_not_null
ON orders (order_no)
WHERE order_no IS NOT NULL;
这个索引既保证了非空 order_no 的唯一性，又允许存在多条 order_no 为 NULL 的记录。这种灵活性是 MySQL 的普通唯一索引做不到的，也是 PostgreSQL 的一个亮点。如果你的业务有类似的"部分唯一"需求，务必记住这个解法。
6. 常见问题与排查技巧实录
6.1 索引失效的几种典型场景
索引建好了，查询还是慢，这种事我碰到过太多次了。排查思路其实不复杂，下面这些场景是出现频率最高的。
函数包裹导致索引失效。 比如 WHERE DATE(created_at) = '2025-01-01'，用 DATE() 函数包裹了 created_at 列，PostgreSQL 无法直接使用 created_at 上的索引，因为它需要先对每行执行函数运算，才能比较结果。解决办法是改写为范围条件：WHERE created_at >= '2025-01-01' AND created_at < '2025-01-02'，或者建表达式索引：CREATE INDEX ON orders (DATE(created_at))。
隐式类型转换导致匹配不上。 比如表里 user_id 是 BIGINT 类型，查询条件却写 WHERE user_id = '123'，PostgreSQL 会尝试把字符串转换成 BIGINT。这种转换通常不会让索引失效，但如果转换规则不明确，可能就无法用索引。排查办法是查看执行计划，确认 Index Cond 的类型是否匹配。
LIKE 模糊匹配的前导通配符。 WHERE order_no LIKE '%12345%' 这种写法，天然没法走 B-Tree 索引，因为索引是按前缀顺序排列的，无法利用后缀匹配。只有 LIKE '12345%' 这种前缀匹配才能走索引。如果业务上确实需要频繁做后缀匹配，考虑用 pg_trgm 扩展配合 gin 索引。
OR 条件导致优化器选择全表扫描。 有些情况下，WHERE status = 1 OR status = 2 并不会使用 status 上的索引，优化器会评估代价后决定是否走索引。如果这个条件筛选出的比例比较大（比如超过 10% 到 20%），全表扫描反而比索引扫描快，优化器就会选择全表扫描。这种情况可以用 UNION ALL 拆分，或者考虑使用 GIN 索引。
6.2 为什么 EXPLAIN ANALYZE 看到的行数估算偏差很大
EXPLAIN ANALYZE 的结果里有两个数字，一个是优化器预估的行数（rows），一个是实际执行后的行数（actual rows）。如果两者偏差很大，比如预估 1000 行，实际只有 10 行，说明表的统计信息过期了，优化器做了错误的判断，可能导致它选择了错误的执行计划。
解决办法很简单，对表重新收集统计信息：
sql复制ANALYZE orders;
在批量插入大量数据之后，这个操作尤其重要。批量插入会导致表的统计信息严重滞后，PostgreSQL 对统计信息的自动更新策略是"当表数据变化量超过某个阈值时触发"，阈值默认是 20%，所以手工 ANALYZE 更可靠。
还有一个容易被忽略的点：EXPLAIN ANALYZE 会真实执行查询，对于 UPDATE、DELETE、INSERT 这类语句，执行后数据会被真正修改。如果不想执行，只想看计划，用 EXPLAIN 就行。如果想分析 DDL 语句，用 EXPLAIN (ANALYZE, BUFFERS) 拿更完整的性能数据。
6.3 索引膨胀与维护：VACUUM 和 REINDEX 的使用时机
PostgreSQL 的 MVCC 机制导致了一个副作用：索引会产生膨胀。简单说，当一行数据被 UPDATE 或 DELETE 后，旧版本的索引项不会立即删除，而是标记为死元组。如果表的更新频率高，时间久了索引就会越来越大，查询性能逐渐下降。
判断索引膨胀程度，可以用一个通用的查询，查看索引的物理大小和实际有效数据量的关系：
sql复制SELECT
pg_size_pretty(pg_indexes_size('orders')) AS total_index_size,
pg_size_pretty(pg_total_relation_size('orders')) AS total_table_size;
如果发现索引大小和表大小接近甚至超过表本身，且数据量并没有增长那么多，大概率就是膨胀了。解决办法是 REINDEX：
sql复制REINDEX INDEX idx_orders_user_status_time;
或者直接重建整个表的索引：
sql复制REINDEX TABLE orders;
REINDEX 会重建索引，释放死元组占用的空间。注意，重建索引期间会锁表，在线上环境要选择合适的窗口，或者在 PostgreSQL 12+ 使用 REINDEX CONCURRENTLY，它不会阻塞读写，但耗时更长、产生更多临时 IO。
另一个常规维护是 VACUUM。普通的 VACUUM 清理死元组，但不会回收索引空间，只有 VACUUM FULL 才会物理收缩表文件，但它会锁表，生产环境慎用。日常建议开启 autovacuum，并定期检查死元组比例。
我曾经维护过一张日增 20 万行的订单表，每周跑一次 REINDEX CONCURRENTLY，成功把查询 P99 延迟从 300ms 降到 50ms 左右。这个操作是真实有效的，不要等索引膨胀到影响业务了才想起来处理。
6.4 一个容易被坑的细节：复合索引无法全部命中的场景
回到复合索引，有一个非常经典的坑：假设索引建的是 (user_id, status, created_at)，查询条件写的是：
sql复制SELECT * FROM orders
WHERE status = 1 AND user_id = 123;
注意条件顺序是反的——status 在前，user_id 在后。这种情况索引能不能生效？
能。因为 SQL 是声明式语言，WHERE 条件的书写顺序不影响优化器的判断，优化器会自动调整条件顺序来匹配最左前缀原则。所以不需要担心条件顺序问题，真正需要担心的是缺少某个前导列：比如 WHERE status = 1 AND created_at > ...，缺少了 user_id 这个最左列，索引就无法使用。
另外，还有一个被很多人忽略的场景：如果复合索引包含多列，但查询条件中前一列是范围条件，后一列是等值条件，比如：
sql复制SELECT * FROM orders
WHERE created_at > now() - interval '30 days' AND status = 1;
如果建的索引是 (created_at, status)，status 的等值条件其实无法在索引内高效使用。因为 created_at 是范围条件，PostgreSQL 会先在索引中找到从某时间点开始的所有记录，然后在这些记录里逐条判断 status 是否等于 1，无法用索引快速定位到 status=1 的分支。这时候索引退化为"范围扫描 + 索引内过滤"，效果不如重新设计索引。
最优解是 (status, created_at) 这样的列顺序：status 等值条件先定位到精确分支，created_at 范围条件在这个分支内顺序扫描。所以前面说的"等值条件放前面，范围条件放后面"，在复合索引设计里真的是核心中的核心。
7. 实操心得与后续扩展
7.1 我在实际项目中踩过的索引设计坑
做了这么多年数据库相关的工作，索引设计上踩过的坑不少，这里挑我印象最深的三点说一说。
第一个教训是：不要过度设计索引。我记得有一段时间，为了让所有查询都快，我几乎给每张表的每个 WHERE 可能用到的列都建了单列索引。结果写入性能明显下降，更新一张 10 万行的表耗时增加了 40%。后来我把单列索引合并成几个复合索引，调整列顺序，写入性能恢复正常，查询性能基本没受损失。索引不是越多越好，而是越精确越好。
第二个教训是：复合索引列顺序一定要从实际查询出发。以前我有个习惯，喜欢把主键列放在复合索引的第一位，觉得这样区分度高，查询快。但有个查询条件是 WHERE created_at BETWEEN ... AND ... AND user_id = 123，我建了 (id, user_id, created_at) 的复合索引，结果这个查询根本没走索引。排查后发现，id 在这个查询里根本用不上，索引的最左列没有映射到查询条件，整个索引就失效了。后来我把复合索引改成 (user_id, created_at)，效果立竿见影。
第三个教训是：索引不是永久的，要定期评估重建。表结构会变、查询模式会变、数据分布会变，以前最优的索引可能半年后就变成累赘了。我会定期（两个月左右）拉一次慢查询日志，对比当前索引设计和实际查询需求，把没用的索引删掉，把新的高频查询需要的索引补上。这个动作叫"索引治理"，是数据库运维里很值得投入的一块。
7.2 后续可以继续深入的方向
既然已经把唯一索引和复合索引的基本功打牢了，接下来的进阶方向有两条主线。
一条是执行计划分析能力。EXPLAIN 的各种参数组合，比如 EXPLAIN (ANALYZE, BUFFERS, FORMAT JSON)，能让你精确了解每一次查询的 IO 成本、内存使用、排序和哈希操作的细节。我会在调优高并发查询时，先用 JSON 格式抓一把完整执行数据，再逐项分析瓶颈在哪一步。这一步学会了，几乎任何数据库的性能问题在你眼里都会清晰很多。
另一条是PostgreSQL 的特色索引类型。GIN 索引适合全文检索和 JSONB 查询，BRIN 索引适合超大的堆表且数据物理排序明显（比如时间序列数据），GiST 适合地理数据和范围类型。这些索引类型在特定场景下的性能收益远超 B-Tree，是 PostgreSQL 区别于很多传统数据库的亮点。等你把 B-Tree 玩熟了，可以找个实际业务场景试试这些高阶索引。
最后说一句实在的：索引是"一劳永逸"程度最高的优化手段，但没有任何一种索引设计可以应对所有查询。最好的方式永远是结合 EXPLAIN ANALYZE 的输出，用数据说话。我希望你读完这篇文章后，能在自己的库上把每个例子都亲手跑一遍，踩一踩这些坑，才能真正理解索引的价值。