PostgreSQL联合索引也叫复合索引，是指在一个索引中包含多个字段的索引结构，它主要用于优化涉及多个查询条件的SQL语句。和单列索引相比，联合索引能更精准地匹配多条件查询，减少数据扫描范围，但设计不当也会造成索引失效或者占用过多存储空间。
联合索引的核心匹配规则
PostgreSQL的联合索引遵循最左前缀匹配原则，这是设计联合索引时最需要关注的基础规则。简单来说，联合索引的字段顺序决定了它可以生效的查询场景，只有查询条件中包含了索引最左侧的连续字段，索引才会被优化器选中使用。
最左前缀原则示例
假设我们创建了一个包含三个字段的联合索引：
-- 创建用户表
CREATE TABLE user_info (
id INT PRIMARY KEY,
province VARCHAR(20),
city VARCHAR(20),
age INT,
register_time DATE
);
-- 创建联合索引，字段顺序为province、city、age
CREATE INDEX idx_user_province_city_age ON user_info (province, city, age);
这个索引可以生效的查询场景包括：
- 仅查询province字段的条件
- 同时查询province和city两个字段的条件
- 同时查询province、city、age三个字段的条件
以下场景无法使用该联合索引：
- 仅查询city字段的条件，跳过了最左侧的province
- 仅查询age字段的条件，不符合最左前缀要求
- 查询city和age两个字段的条件，缺少最左侧的province
联合索引字段顺序设计原则
合理的字段顺序能让联合索引覆盖更多查询场景，同时提升查询效率，设计时可以参考以下三个维度：
1. 查询频率优先
将查询中出现频率最高的字段放在联合索引的最左侧，这样能最大程度保证索引被多个查询复用。比如如果大部分查询都会带上province条件，那么province应该作为联合索引的第一个字段。
2. 字段区分度优先
区分度越高的字段放在越靠左的位置，区分度指的是字段的不同值数量占总行数的比例，比例越高区分度越高。高区分度字段放在前面能更快缩小扫描范围，比如用户表的手机号字段区分度远高于性别字段，若两者同时出现在查询条件中，手机号应该放在更左侧。
3. 范围查询字段放最后
如果某个字段经常用于范围查询（比如大于、小于、between、like前缀匹配除外），建议将其放在联合索引的最后一位。因为范围查询之后的字段无法继续使用索引的有序性进行匹配，放在最后能减少索引失效的概率。
比如常见的查询条件是province等于某个值，age大于某个值，那么联合索引应该设计为(province, age)，而不是(age, province)，这样province的等值查询能先匹配，age的范围查询也能继续使用索引。
联合索引的适用场景
联合索引并不是所有场景都适用，以下场景使用联合索引能取得更好的效果：
- 多条件等值查询：查询条件包含多个字段的等值匹配，联合索引能一次性定位到目标数据
- 覆盖索引场景：如果查询的字段都包含在联合索引中，数据库不需要回表查询数据行，能大幅提升查询速度
- 排序和分组优化：如果查询的排序或者分组字段和联合索引的字段顺序、方向一致，索引可以直接提供有序数据，避免额外的排序操作
覆盖索引示例
如果我们的查询只需要获取province、city、age三个字段，那么前面创建的idx_user_province_city_age索引就能实现覆盖索引，不需要回表查询user_info表的其他字段：
-- 该查询可以直接使用联合索引返回结果，不需要回表 SELECT province, city, age FROM user_info WHERE province = '广东' AND city = '深圳';
联合索引设计的常见误区
误区1：索引字段越多越好
联合索引的字段数量不是越多越好，字段越多索引占用的存储空间越大，写入数据时的索引维护成本也越高。一般建议联合索引的字段数量不超过3个，除非有明确的覆盖索引需求。
误区2：忽略查询条件的顺序
很多开发者认为查询条件中字段的顺序需要和联合索引的字段顺序一致，实际上PostgreSQL的优化器会自动调整查询条件的顺序，只要条件中包含了最左前缀的连续字段，无论条件书写顺序如何，索引都可以生效。
误区3：重复创建功能重叠的索引
比如已经创建了(province, city, age)的联合索引，就不需要再单独创建(province)的单列索引，因为联合索引已经可以覆盖仅查询province的场景，重复创建只会浪费存储空间，增加写入开销。
联合索引效果验证方法
设计完联合索引后，可以通过EXPLAIN命令查看查询计划，确认索引是否被正确使用：
-- 查看查询计划，确认是否使用了联合索引 EXPLAIN SELECT * FROM user_info WHERE province = '广东' AND city = '深圳' AND age > 20;
如果查询计划的type显示为index或者range，并且key显示为创建的联合索引名称，说明索引已经生效。如果显示的是seq scan全表扫描，说明索引没有被使用，需要检查查询条件是否符合最左前缀原则，或者索引是否因为数据量过少等原因没有被优化器选中。
另外需要注意，联合索引虽然能提升查询性能，但会增加插入、更新、删除操作的开销，因为每次数据变更都需要同步维护索引结构。因此不要在更新频繁的表上创建过多联合索引，需要在查询性能和写入性能之间做好平衡。
PostgreSQL联合索引复合索引索引设计查询优化修改时间：2026-06-11 21:21:27