在PostgreSQL中建立多列索引（也叫复合索引或联合索引）时，列的顺序并不是一个可以随意摆放的细节。B树类型的多列索引在内部是按照声明顺序逐层比较键值来组织树的，查询条件能否利用索引、能利用多少，直接取决于条件中的列是否匹配索引的最左前缀。很多慢查询背后，其实就是把区分度低的列放在了前面，或者把范围查询列放到了等值查询列之前，导致索引只能用到一部分甚至完全失效。
多列B树索引的底层匹配逻辑
PostgreSQL默认的B树多列索引在排序时，先按照第一列排序，第一列相同的行再按第二列排序，以此类推。这种结构意味着索引的检索过程也是先定位第一列的范围，再在已缩小的范围内定位第二列。如果查询没有对第一列给出约束，数据库通常无法在B树中做高效的有序跳转，只能退化为全索引扫描或全表扫描。
最左前缀原则要求查询条件至少包含索引最左边的连续列。例如索引定义为(a, b, c)，那么where a=1、where a=1 and b=2都能利用索引，但where b=2单独出现时，在没有额外索引的情况下就难以命中该联合索引的有序结构。值得注意的是，在PostgreSQL的B树实现里，如果第一列是等值条件，第二列即使是范围条件也能继续缩小区间；但如果第一列本身是范围条件，第二列基本无法再利用索引做进一步的范围裁剪。
我们可以通过简单的建表与索引来观察这一点。以下代码创建了测试表并建立了两种顺序的多列索引：
create table order_log (
user_id int,
create_date date,
amount numeric
);
create index idx_user_date on order_log (user_id, create_date);
create index idx_date_user on order_log (create_date, user_id);
insert into order_log
select (random()*1000)::int,
current_date - (random()*365)::int,
random()*100
from generate_series(1, 100000);
上述两个索引物理结构不同，对后续查询的适用性也完全不同，不能互相替代。
不同列顺序在典型查询下的性能差异
假设我们想查询某个用户在某段时间内的订单。当索引是(user_id, create_date)时，where user_id=123 and create_date between '2023-01-01' and '2023-02-01'可以先用user_id精准定位到该用户的所有行，再在较小集合内按日期过滤，执行计划通常显示Index Scan。反之，如果索引是(create_date, user_id)，同样的条件也能用上索引，但它是先按日期圈定区间，再在其中找user_id，当日期区间很大时，扫描的索引块会明显变多。
更极端的反例是范围条件在前、等值条件在后。例如索引为(create_date, user_id)，查询写成where create_date > '2023-01-01' and user_id=123。此时create_date是范围，PostgreSQL只能在日期范围内做扫描，user_id的等值约束无法在B树遍历阶段有效减少分支，只能作为过滤条件，执行计划中可能出现Bitmap Index Scan加Recheck，效率远低于前者。
我们用explain来直观对比：
explain (analyze, buffers) select * from order_log where user_id = 500 and create_date >= '2023-06-01'; explain (analyze, buffers) select * from order_log where create_date >= '2023-06-01' and user_id = 500;
在idx_user_date存在时，第一条语句往往只需访问极少缓冲区；第二条语句若只有idx_date_user，则缓冲区命中数取决于日期区间跨度。这种差异在数据量达到千万级时会从毫秒级扩大到秒级。
如何根据业务查询模式设计列顺序
设计多列索引顺序的核心依据是业务中最常用且最具筛选能力的列放前面。通常把等值查询频率高、区分度大的列作为索引第一列；范围查询列尽量靠后。如果某列经常单独出现在where中，应考虑它是否需要自己的单列索引，或者作为联合索引的最左列。
另一个常见误区是认为可以把所有查询列都堆进一个联合索引。实际上索引维护有写入成本，列数过多会导致插入变慢、膨胀加剧。建议先用pg_stat_statements统计慢查询与高频SQL，抽取出稳定的where组合，再针对性建立两到三列的索引。例如报表类查询常按部门加日期，就建(dept_id, report_date)；用户维度查询常按用户加状态，就建(user_id, status)。
当存在多种列顺序需求时，也可以利用PostgreSQL的索引只包含最左前缀这一特性，配合少量单列索引来覆盖。例如已有(user_id, create_date)，若偶尔需按create_date单独查，再补一个(create_date)单列索引，比盲目建(create_date, user_id)更省空间。最后记得在测试环境用真实数据量和分布做explain验证，避免凭直觉定顺序。
select
indexrelname,
idx_scan,
idx_tup_read,
idx_tup_fetch
from pg_stat_user_indexes
where relname = 'order_log'
order by idx_scan desc;
通过上面的统计视图，你能清楚看到哪个索引真正被使用、扫描了多少元组，从而判断列顺序是否合理。
PostgreSQL多列索引索引列顺序修改时间：2026-08-18 13:16:29