PostgreSQL 索引实战：从单列索引到复合索引与性能优化

上个月我帮一位做电商的朋友排查线上慢查询，订单表才二十多万行，按创建时间倒序查个订单列表，每次都稳稳地跑两秒多。表结构不算复杂，索引却一个都没建。我补上一条再简单不过的单列索引之后，同样的查询从 2.1 秒降到了 38 毫秒。这事听起来像是数据库入门第一课，但在真实项目里隔三差五就能遇到，很多人对索引的认知其实一直停留在“建索引能变快”这个模糊的层面上，至于为什么快、怎么建最合理、建完怎么验证，往往是支支吾吾的。

这篇文章就是写给这部分人看的。我会从最基础的单列索引讲起，覆盖复合索引、唯一索引、表达式索引、部分索引，把创建语法、验证方法、执行计划分析、以及我在实际运维和开发中踩过的坑，都按自己的实践顺序捋一遍。适合刚接触 PostgreSQL 的开发者、想系统补一补索引基础的数据工程师，以及在面试里被问到“索引底层到底是怎么回事”时说不清楚的同学。

1. 在动手建索引之前，先搞清楚它到底在解决什么问题

1.1 没有索引时，PostgreSQL 是怎么查数据的

PostgreSQL 的表数据默认存储在堆表里，所谓堆表，就是数据按照插入顺序物理地堆放，并没有按某个业务键排序。假设 users 表有 20 万行数据，每行平均 100 字节，那差不多是 20MB 的数据量。如果要执行 SELECT * FROM users WHERE email = 'someone@example.com'，在没有索引的情况下，数据库只能把 20 万行数据从头到尾读一遍，逐行比较 email 字段，这个过程叫顺序扫描，执行计划里会显示 Seq Scan。

顺序扫描本身不是坏东西，数据量小的时候它反而是最优解，因为顺序读磁盘的效率很高。问题在于数据量一旦上去，比如千万行、上亿行，全表扫描的代价就是灾难性的。这里有一个很直观的计算方式：数据库以页为单位读数据，默认每页 8KB。20MB 的表大约有 2560 页，读一页少则几毫秒，多则几十毫秒，取决于磁盘类型和缓存命中情况。你把这个数字乘上查询频率，性能自然就崩了。

索引解决的就是这个问题——它把“从头翻书”变成了“查目录”。目录本身是一棵 B-tree，按照你指定的列排序存储，查询引擎可以在对数级别的时间内定位到目标数据，然后通过行指针回表取出完整记录。同样是那 20 万行数据，三层高的 B-tree 索引足以支撑千万级数据量的快速查找，整个过程只需要读几个页面。

1.2 索引能帮到哪些场景，帮不到哪些场景

先说能帮到的场景，这决定了你在什么需求下应该优先考虑索引：

• 等值查询，比如 WHERE status = 'paid'
• 范围查询，比如 WHERE created_at BETWEEN '2024-01-01' AND '2024-01-31'
• 排序操作，比如 ORDER BY created_at DESC
• 表连接，比如 JOIN orders ON orders.user_id = users.id
• 唯一性约束，比如邮箱、订单流水号不允许重复

再说帮不到的场景，这部分容易被忽略：

• 数据量很小的表，几十行上百行的表全表扫描可能比走索引更快，建索引纯属浪费
• 选择性很差的列，比如性别、只有两三个取值的状态列，索引带来不了多少性能提升，却要白白承担写入开销
• 写入非常频繁的表，如果大多数操作是 INSERT 和 UPDATE，过多的索引会让每一次写入都变慢
• 查询条件里对列做了函数运算但没建对应的表达式索引，比如 WHERE upper(email) = 'ABC@EXAMPLE.COM'，普通索引帮不上忙

这部分内容看起来像常识，但我在项目里见过很多“凭感觉建索引”的开发同学，什么列都敢加索引，结果查询没加速，写入倒是掉了一截。先搞清楚索引的边界，后面做索引设计才不会跑偏。

2. 从 B-tree 到回表：简单索引没你想的那么简单

2.1 为什么数据库选了 B-tree，而不是二叉树

很多人第一次看 B-tree 数据结构时都会有个疑问：二叉搜索树不是更简单吗？为什么会整出一个多叉树来？

核心原因在磁盘 I/O。数据库的数据最终是落盘的，而磁盘随机读写的代价远远高于内存访问。二叉搜索树在数据量大的时候会变得很高，比如 100 万条数据，最理想情况下二叉树高度也有 20 层，意味着查找一个值可能要访问 20 次磁盘页面。而 B-tree 是多叉的，一个节点就是一个 8KB 的页面，里面可以存储成百上千个键值。同样 100 万条数据，B-tree 通常只有三层高：根节点一层、中间节点一层、叶子节点一层。三层意味着最多 3 次磁盘 I/O 就能定位到目标，这个差距在数据库场景里是决定性的。

B-tree 还有一个重要特性是自平衡：所有叶子节点都在同一层，无论你插入多少数据，树的高度增长都极其缓慢。这也是为什么 PostgreSQL 默认就用 B-tree 作为普通索引的访问方法，它在绝大多数等值和范围查询场景下表现稳定。

2.2 回表、覆盖索引和 Index Only Scan

索引叶子节点里存的不只是键值，还存了一个指向堆表数据行的物理指针，在 PostgreSQL 里叫 TID，也就是行所在的页号和页内偏移量。查询过程分两步：先从 B-tree 里找到满足条件的键值和 TID，再到堆表里根据 TID 取出完整的数据行，这一步叫回表。

回表本身有随机 I/O 成本，所以很多优化手段都在想方设法避免回表。如果你查询的列全部包含在索引中，比如只查 SELECT created_at FROM orders WHERE created_at BETWEEN ...，而索引恰好建立在 created_at 上，那么 PostgreSQL 可以直接从索引页面获取数据，不需要回表，执行计划里显示为 Index Only Scan。这是理想情况，实际业务里很难让所有查询都命中覆盖索引，但理解这个机制对读懂执行计划很重要。

还有一个和回表相关的细节：PostgreSQL 的 MVCC 机制下，Index Only Scan 需要配合可见性映射来判断哪些行是当前事务可见的。如果表上近期更新过大量数据，可见性映射不够新，数据库还是得回表确认可见性。所以覆盖索引的效率高低，并不完全取决于索引本身，还取决于表的真空状态。

2.3 PostgreSQL 常见的索引类型一览

很多初学者以为索引就是一种东西，实际上 PostgreSQL 提供了好几种访问方法，每种适合不同的场景：

这篇文章里说的“简单索引”，主要指默认的 B-tree 索引，它覆盖了日常开发 90% 以上的需求。剩下的几种访问方法各有适用场景，比如 GIN 索引在 JSONB 和全文检索里表现很好，BRIN 索引在日志类大表上性价比极高，这些是后续进阶的方向，在这里先建立认知即可。

3. 一行命令创建索引：语法、命名与执行计划验证

3.1 最基础的创建语法和命名规范

PostgreSQL 创建索引的语法很简洁：

sql复制CREATE INDEX idx_orders_created_at ON orders (created_at);

这条语句的含义是：在 orders 表的 created_at 列上建立一棵 B-tree 索引，索引的物理名称叫 idx_orders_created_at。命名是我习惯加的，如果不写，PostgreSQL 会自动生成一个类似 orders_created_at_idx 的名字，其实也能用，但手工命名在后续维护时能让你一眼看出这个索引属于哪张表、覆盖哪个列，尤其在数据库里上百个索引的时候，这点非常关键。

我个人的命名规则是 idx_表名_列名，如果多个列就是 idx_表名_列1_列2，唯一索引则用 uq_表名_列名 开头，部分索引会在末尾加简短后缀。这不是硬性规定，但建立一个统一的规则能避免很多管理上的混乱。

创建索引时还可以指定一些选项，比如：

sql复制CREATE INDEX idx_orders_created_at ON orders (created_at)
WHERE created_at >= '2024-01-01';

这就是一个部分索引，我在第 5 章会详细展开。还有一个常用选项是 TABLESPACE，可以把索引放在单独的表空间，比如一块高速 SSD 上，但普通业务用默认表空间就够了，没必要过度设计。

3.2 在可视化工具里怎么操作

如果你用的是 pgAdmin，创建索引不需要敲命令：左侧展开目标表，右键点击 Indexes，选择 Create Index，在弹出的面板里填索引名、选择访问方法（默认就是 btree），然后在下方的 Columns 里选择要建索引的列。界面操作和命令行是等价的，适合不想记命令、或者想更直观看到索引列表的场合。

但我的建议是，生产环境里的索引变更尽量用脚本而不是界面，因为脚本可以放进版本控制系统，能追溯谁在什么时间改了什么。数据库结构应该是基础设施的一部分，而不是停留在某个人脑中的知识点。这一点在团队合作时尤其重要，我见过不止一次因为界面操作漏了记录，导致后来排查问题时根本不知道某个索引是谁建、为什么建的尴尬情况。

3.3 用 EXPLAIN 验证索引是否真的生效

建完索引之后第一件事，不是直接说“搞定”，而是验证它真的被查询用上了。PostgreSQL 提供了解释执行计划的命令：

sql复制EXPLAIN SELECT * FROM orders WHERE created_at >= '2024-01-01';

建索引之前，你大概率会看到这样的输出：

code复制Seq Scan on orders  (cost=0.00..4888.20 rows=12000 width=56)
  Filter: (created_at >= '2024-01-01')

建索引之后，执行计划会变成：

code复制Index Scan using idx_orders_created_at on orders  (cost=0.42..109.80 rows=12000 width=56)
  Index Cond: (created_at >= '2024-01-01')

注意里面的关键字变化：Seq Scan 变成了 Index Scan using idx_orders_created_at，并且出现了 Index Cond，这就说明索引真的被用上了。cost 的第一位是启动成本，第二位是总成本，可以看到走索引之后总成本从 4888 降到了 109，这就是性能提升的直接体现。

需要提醒的是，EXPLAIN 只显示执行计划，并不真正执行查询。如果你想知道真实执行时间，用 EXPLAIN ANALYZE，它会把 SQL 跑一遍，并且输出实际执行耗时和返回行数。

还有一类常见情况是：索引明明建好了，执行计划却还是 Seq Scan。我在项目里遇到过好多次，原因通常有以下几种：

• 表的数据量太小，查询规划器认为全表扫描比走索引更快
• 查询条件里写了 LIKE '%abc%'，前导通配符导致 B-tree 索引无法使用
• 统计信息过期，导致规划器估算偏差，此时执行 ANALYZE 表名; 刷新统计信息

排查的时候不要一上来就怀疑索引建错了，先看数据量和执行计划里的成本估算，再决定下一步。

4. 比单列索引更常用的两种：复合索引与唯一索引

4.1 复合索引的列顺序到底怎么定

单列索引是最基础的形态，但真实业务里查询条件往往涉及多个列，这时候就需要复合索引。比如订单列表最常见的场景是按用户查订单，同时还要按时间排序：

sql复制SELECT * FROM orders
WHERE user_id = 1001
ORDER BY created_at DESC;

如果只给 user_id 建了单列索引，查询时可以先准确找到目标用户的订单，但排序还得再做一次。更合理的方案是建一个复合索引：

sql复制CREATE INDEX idx_orders_user_created ON orders (user_id, created_at);

这个索引同时组合了 user_id 和 created_at，B-tree 会先按 user_id 排序，在同一个人内部再按 created_at 排序。于是，对于上面的查询，它既能快速定位 user_id，又天然拿到了排好序的 created_at，省掉一次排序操作。

复合索引最关键的知识点叫“最左前缀原则”：索引 (user_id, created_at) 可以支撑形如 WHERE user_id = 1001 的查询，也能支撑 WHERE user_id = 1001 AND created_at >= '2024-01-01' 这种查询，但如果查询条件里只有 created_at，没有 user_id，这个复合索引就完全无能为力。原因很简单：B-tree 排序是以最左边的列为第一关键字，没有第一关键字的约束，整棵树的顺序对当前查询来说就是乱的。

在设计复合索引列顺序时，我有一个经验法则：等值条件放前面，范围条件放后面。原因也很直白，等值条件能把搜索空间瞬间缩小到一个固定的子树，范围条件在等值条件的基础上做排序和范围遍历是最自然的。比如 WHERE user_id = 1001 AND created_at BETWEEN ...，user_id 是等值，放前面；created_at 是范围，放后面，这样一条索引就能把这个查询全部覆盖。

还有一个常见误解是：复合索引建得越多越好，干脆把所有查询可能用到的列都塞进去。这是不对的。复合索引不是列越多越强，每增加一个列，索引体积变大、写入维护成本变高，而且只有当查询条件匹配上最左前缀时才能用。盲目的“大而全”索引，往往是数据库性能问题的另一个来源。

4.2 唯一索引：约束数据，捎带优化查询

唯一索引（UNIQUE INDEX）在业务里非常常见，它同时承担两个职责：约束数据唯一性，以及加速查询。

比如用户表里要求邮箱不允许重复，可以这样建：

sql复制CREATE UNIQUE INDEX uq_users_email ON users (email);

或者在建表的时候直接加 UNIQUE 约束：

sql复制CREATE TABLE users (
    id BIGSERIAL PRIMARY KEY,
    email VARCHAR(255) UNIQUE,
    name TEXT
);

PostgreSQL 会自动为 UNIQUE 约束创建对应的唯一索引，效果和显式建索引基本一样。唯一索引的价值在于：它能让数据库从最底层拦截重复数据，而不是靠应用层先查再插，这对并发场景尤其重要。试想两个请求同时插入相同的 email，应用层先查再插会出现竞态条件，而唯一索引直接在数据库层面把第二条插入语句拒绝掉，返回唯一约束冲突。

写应用的时候可以用 ON CONFLICT 配合唯一索引做幂等插入：

sql复制INSERT INTO users (email, name)
VALUES ('someone@example.com', '张三')
ON CONFLICT (email) DO UPDATE SET name = EXCLUDED.name;

这个写法在用户注册、订单流水写入等场景里非常实用，能避免大量重复数据问题。

有一个很容易踩的坑：PostgreSQL 的唯一约束在 NULL 值上不去重。也就是说，email 列如果做了唯一索引，允许存在多行 email 为 NULL 的记录，因为 SQL 语义里 NULL 不等于 NULL。很多业务希望邮箱为空也只允许一条，这需要额外用部分唯一索引来处理，我在第 5 章会讲。

另外值得区分的是主键索引和唯一索引：一个表只能有一个主键，主键本身隐含非空和唯一，PostgreSQL 会自动为主键创建唯一索引。而唯一索引则没有数量限制，你可以在多个列上各建一个唯一索引，只要有这个业务约束需求。本质上，主键是逻辑上的标识符，唯一索引是更通用的约束手段。

5. 进阶但不复杂：表达式索引与部分索引

5.1 表达式索引：给计算后的结果建索引

普通索引建在原始列上，但如果查询条件对列做了函数运算，比如：

sql复制SELECT * FROM users WHERE lower(email) = 'someone@example.com';

这时候 uq_users_email 这种建立在 email 原始值上的普通索引是走不了的，因为数据库需要对每一行做一次 lower(email) 运算才能比较，而索引里存的是原始 email，没法通过 B-tree 快速查找。执行计划大概率是全表扫描。

解决办法也很直接：既然查询总是拿 lower(email) 去比较，那就给 lower(email) 建索引：

sql复制CREATE INDEX idx_users_lower_email ON users (lower(email));

这就是表达式索引。建完之后，同样的查询就可以走索引了。一个很实用的组合是：在用户表里既要求逻辑上的邮箱唯一，又允许用户输入大小写不同的地址，那可以建一个唯一表达式索引：

sql复制CREATE UNIQUE INDEX uq_users_email_lower ON users (lower(email));

这样不但查询能走索引，还能从数据库层面彻底阻止 a@b.com 和 A@B.COM 这种大小写不同的重复邮箱写入。

表达式索引有一个非常重要的注意事项：SQL 查询里的表达式必须和索引里的表达式保持一致，包括空格、括号、类型转换都不能差。只要写法有细微不同，规划器就可能匹配不上索引。我在项目里就见过这样的情况，索引建的是 (date(created_at))，查询写的是 WHERE created_at >= '2024-01-01' AND created_at < '2024-01-02'，结果因为表达式形态完全不同，索引完全没被用上。所以使用表达式索引时，建议在团队内统一查询写法，或者干脆把这个规则写进代码规范里。

另外一个隐含成本是表达式索引的体积通常比原始列索引大，因为函数运算结果需要额外的存储空间。不过通常可以接受，毕竟它能解决真实的查询性能问题。

5.2 部分索引：只索引真正需要的数据

部分索引是 PostgreSQL 一个被严重低估的功能。它允许你只对表中满足某个条件的行建立索引，语法上就是在 CREATE INDEX 末尾加一个 WHERE：

sql复制CREATE INDEX idx_orders_pending_created ON orders (created_at)
WHERE status = 'pending';

假设订单表里有 100 万行历史数据，其中只有几千行是 pending 状态，而业务上绝大多数对订单列表的查询都带有 WHERE status = 'pending' 条件。如果对整个表的 created_at 建索引，索引体积可能达到几十 MB，而且每次订单状态更新都要维护索引。但用部分索引，B-tree 里只包含 status 为 pending 的行，索引体积小得可怜，维护成本也大幅降低，查询性能反而更快。

PostgreSQL 的查询规划器会自动识别查询条件是否包含部分索引的过滤条件。比如执行：

sql复制SELECT * FROM orders
WHERE status = 'pending'
  AND created_at >= '2024-06-01'
ORDER BY created_at DESC;

规划器会意识到索引 idx_orders_pending_created 的 WHERE 条件 status = 'pending' 已经被查询条件覆盖，所以可以放心地使用这个索引，不必额外在全表上加 status 的过滤。

部分索引还有一个经典用法，就是配合唯一索引实现并发场景下的业务约束。比如业务允许用户有多条订单，但同一时间只能有一条待支付订单：

sql复制CREATE UNIQUE INDEX uq_orders_user_pending
ON orders (user_id)
WHERE status = 'pending';

这个索引能保证任意用户只有一条 pending 状态的订单，一旦支付完成或取消，状态变了，该行就从索引里出局，用户可以继续插入下一条 pending 订单。这种用部分唯一索引实现复杂业务约束的做法，在常规开发里很少见，但它比靠应用层加锁或者事务隔离要干净得多。

使用部分索引的代价是查询条件必须和索引条件匹配，否则索引就是摆设。这也要求开发者在建索引之前，认真分析业务场景里哪些查询路径是高频的，而不是盲目地全表建索引。

6. 索引不是免费的：成本账与建索引时机

6.1 索引的三笔显性账

很多初学者容易陷入一个误区：索引是越多越好的优化手段。实际上索引是有成本的，而且在某些场景下成本相当可观。第一笔账是写入开销。每次 INSERT，PostgreSQL 除了往堆表里插数据，还要往这张表上建立的每个索引里插一条记录。UPDATE 更麻烦，如果更新的列正好在索引列上，索引也要跟着修改；即使更新的列不在索引里，PostgreSQL 的 MVCC 机制也会因为行的版本变化而影响索引结构。DELETE 同样需要清理索引项。表上的索引越多，写入路径就越长，这种开销在高并发写入下会被放大得非常明显。

第二笔账是存储开销。索引本身就是一份独立的数据，占据磁盘空间。假设某表数据占 500MB，建了 4 个索引，每个索引平均下来也有 100MB 到 200MB，磁盘占用轻松翻倍。对自建服务器来说这可能不是核心痛点，但对云数据库来说，存储成本是真实存在的。

第三笔账是维护开销。PostgreSQL 的 autovacuum 会定期清理过期的行版本和索引条目，索引越多、体积越大，autovacuum 需要扫描和处理的数据就越多，消耗的 I/O 和 CPU 资源也会上升。在业务高峰期，这些后台任务可能和线上查询抢资源。

我在实际项目里见过一个比较极端的案例：报表表上堆了十几个索引，数据量不大，写入频率还高，结果每次批量写入都要等索引更新完才返回，整个链路被拖慢了好几倍。最后删掉了一半几乎没被用过的索引，写入延迟立刻好转了。索引不是“建了不吃亏”，它是一张需要持续付账的账单。

6.2 哪些索引是“不该建”的

那具体什么情况下不该建索引，或者该删掉？我总结了几条经验：

• 选择性差的列不要建普通索引。所谓选择性，就是这个列的取值种类和总行数的比例。性别列只有两个取值，任何查询都会命中将近一半的数据，这时候与其走索引回表，不如直接顺序扫描。判断选择性时可以在 psql 里用一条简单的查询：SELECT count(DISTINCT column_name) FROM table_name;，如果这个值相对于总行数很小，那就要警惕了。

• 频繁更新的列要慎重。如果一个列的值经常被 UPDATE，比如状态字段、计数器字段，索引维护的代价会持续存在。除非查询模式非常依赖这个列，否则三思而后行。

• 小表不要建索引。表只有几千行甚至几百行，全表扫描的代价可能只有几毫秒，而索引 B-tree 的搜索还要经过根节点、中间节点、叶子节点多级访问，根本快不到哪去。

• 长期没有被使用的索引应该删掉。PostgreSQL 提供了系统视图 pg_stat_user_indexes，可以看到每个索引被扫描的次数。查询一下：

sql复制SELECT
    schemaname,
    relname AS table_name,
    indexrelname AS index_name,
    idx_scan,
    idx_tup_read,
    idx_tup_fetch
FROM pg_stat_user_indexes
WHERE idx_scan = 0
ORDER BY relname, indexrelname;

idx_scan 表示该索引被执行计划选中的次数，如果是 0，说明从服务启动到现在，这个索引从未被使用过。对于这样的索引，我的建议是先在非生产环境确认没有查询依赖，再考虑删除。别被“万一以后用得上”绑架，数据库里每一个索引都在持续支付成本，真正有价值的索引应该是为查询服务的，而不是作为心理安慰存在。

不过有个细节要注意：idx_scan = 0 不一定代表索引无用。有些唯一索引是业务唯一性约束的一部分，即使没有被当作查询加速手段使用，也必须保留，否则唯一性就没法保证。删除这类索引前，一定要先搞清楚它的约束语义。

7. 索引的日常保养：膨胀、失效与重建

7.1 索引为什么会膨胀

很多人在运维 PostgreSQL 一段时间后会惊讶地发现：表的行数没怎么变化，索引体积却一直在涨。这就是典型的索引膨胀，英文术语叫 index bloat。

原因和 PostgreSQL 的 MVCC 机制有关。简单说，更新一行数据时，PostgreSQL 不会原地修改，而是生成一个新版本的行，旧版本在事务隔离机制里可能还要被其他事务读到。随着版本不断更迭，索引结构里的旧条目不会立即被删除，只有在 vacuum 清理之后，页面上的空间才能被重新使用。如果 autovacuum 的运行频率和表的更新频率不匹配，索引页面上就会堆积大量已死条目，索引体积随之膨胀，查询效率自然下降。这个过程可以类比成一个仓库里堆了很多过期货物，仓库本身越来越大，但真正能用的货架空间却没有增加。

日志表、状态表这类频繁 UPDATE 和 DELETE 的表最容易出现这个问题。我在一个订单历史表上遇到过索引膨胀率超过 60% 的情况，索引体积从 200MB 涨到了 500MB，查询性能有很明显的退化。它不是索引逻辑结构错了，而是物理空间长期没得到回收。

7.2 怎么发现索引状态异常

定期检查索引体积和膨胀率应该成为数据库维护的固定动作。最简单的检查方法是查看索引占用的磁盘空间：

sql复制SELECT
    indexrelname,
    pg_size_pretty(pg_relation_size(indexrelid)) AS index_size
FROM pg_stat_user_indexes
ORDER BY pg_relation_size(indexrelid) DESC;

如果某些索引的膨胀已经明显影响业务，可以考虑用扩展模块 pgstattuple 来衡量实际未使用空间占页面总空间的比例，这是判断膨胀率的正规途径。安装扩展：

sql复制CREATE EXTENSION pgstattuple;
SELECT * FROM pgstatindex('idx_orders_created_at');

重点看 free_space 字段，它表示索引中空闲空间的百分比。如果这个值长期在 20% 以上，而且数据量没有快速增长，基本可以判断索引需要整理一次了。

7.3 重建与删除的正确姿势

确认索引膨胀之后，重建是常见手段。PostgreSQL 提供了简洁的 REINDEX 命令：

sql复制REINDEX INDEX idx_orders_created_at;

也能直接重建整张表的所有索引：

sql复制REINDEX TABLE orders;

需要提醒的是，早期的 REINDEX 在执行过程中会持有表的锁，期间相关写入和查询都会受影响。PostgreSQL 12 之后引入了 CONCURRENTLY 选项，可以在不长时间阻塞读写的前提下重建索引：

sql复制REINDEX INDEX CONCURRENTLY idx_orders_created_at;

CONCURRENTLY 方式会在后台创建新索引，然后切换，期间占用更多磁盘空间，但业务无感知。我一般在生产环境首选这种方式，尤其是在数据库压力比较大的时候。唯一要注意的是，这种方式不能在事务块里执行，如果你用 psql 的 BEGIN; ... COMMIT; 包裹会报错。

同理，删除无用索引也有并发安全版本：

sql复制DROP INDEX CONCURRENTLY idx_orders_created_at;

我在项目里删索引从来不用普通 DROP INDEX，因为在大型表上它会长时间锁表，阻塞线上业务。用 CONCURRENTLY 虽然耗时会长一点，但对业务的影响几乎可以忽略。

最后说一个我踩过坑之后的习惯：任何索引变更，先写在测试库跑，确认执行计划符合预期，再拿到生产库在低峰期操作。测试环境和生产环境的数据量不同，规划器的选择也可能不同，所以生产库上的验证不能省。索引维护不是“一劳永逸”的工作，把它当成数据库巡检清单里的一项固定动作，比出了问题再救火要省心得多。

这个内容如果你还想继续深入，可以沿着两条线走：一条是去研究 PostgreSQL 里的 GIN 和 BRIN 索引，它们在 JSONB 查询和日志大表场景下能带来极高的性价比；另一条是学习 pg_stat_statements 和慢查询日志分析，用真实执行频率和数据分布来决定索引该建在哪几列上。我个人在后一条线上受益最多，很多看似复杂的索引问题，其实都是对数据分布和查询模式理解不够造成的。