场景：
> Postgresql 8.4,表大约有一百万行
>列c1中的值可以包含大约100个不同的值.我们可以假设值是均匀分布的,因此我们对每个可能的值都有大约10000行.
>列c2可以有1000个不同的值.每个可能的值都有1000行.
搜索数据时,条件始终包含这两列的值,因此该表具有组合c1和c2的多列索引.如果您只使用一列进行过滤查询,我已经阅读了多列索引中正确ordering the columns的重要性.在我们的场景中情况并非如此.
我的问题是这个：
鉴于其中一个过滤器选择的数据量要小得多,如果第一个索引是最具选择性的索引(允许较小的一个索引),我可以提高性能吗？在我看到引用文章中的图形之前,我从未考虑过这个问题：
图片取自参考文章约multicolumn indexes.
查询使用两列中的值进行过滤.我没有使用一列进行过滤的查询.所有这些都是：WHERE c1 = @ ParameterA AND c2 = @ ParameterB.还有这样的条件：WHERE c1 =“abc”AND c2 LIKE“ab％”
由于您参考网站use-the-index-luke.com,请考虑以下章节：
Use The Index,Luke › The Where Clause › Searching For Ranges › Greater,Less and BETWEEN
它有一个完美匹配你的情况的例子(双列索引,一个测试相等,另一个测试范围),解释(更多那些漂亮的索引图形)为什么@ypercube’s advice是准确的并总结起来：
Rule of thumb: index for equality first — then for ranges.
只有一列好吗？
对于只有一列的查询,该做什么似乎很清楚.关于这些相关问题的更多细节和基准：
> Working of indexes in PostgreSQL
> Is a composite index also good for queries on the first field?
选择性较低的列首先？
除此之外,如果两个列只有相同的条件怎么办？
没关系.把列放在第一位,更有可能获得自己的条件,这实际上很重要.
考虑这个演示,或自己重现.我创建了一个包含100k行的两列简单表.一个很少,另一个有很多不同的值：
CREATE TEMP TABLE t AS SELECT (random() * 10000)::int AS lots,(random() * 4)::int AS few FROM generate_series (1,100000); DELETE FROM t WHERE random() > 0.9; -- create some dead tuples,more "real-life" ANALYZE t; SELECT count(distinct lots) -- 9999,count(distinct few) -- 5 FROM t;
查询：
SELECT * FROM t WHERE lots = 2345 AND few = 2;
EXPLAIN ANALYZE输出(排除缓存效果的最佳值为10)：
Seq Scan on t (cost=0.00..5840.84 rows=2 width=8)
(actual time=5.646..15.535 rows=2 loops=1)
Filter: ((lots = 2345) AND (few = 2))
Buffers: local hit=443
Total runtime: 15.557 ms
添加索引,重新测试：
CREATE INDEX t_lf_idx ON t(lots,few);
Index Scan using t_lf_idx on t (cost=0.00..3.76 rows=2 width=8)
(actual time=0.008..0.011 rows=2 loops=1)
Index Cond: ((lots = 2345) AND (few = 2))
Buffers: local hit=4
Total runtime: 0.027 ms
添加其他索引,重新测试：
DROP INDEX t_lf_idx; CREATE INDEX t_fl_idx ON t(few,lots);
Index Scan using t_fl_idx on t (cost=0.00..3.74 rows=2 width=8)
(actual time=0.007..0.011 rows=2 loops=1)
Index Cond: ((few = 2) AND (lots = 2345))
Buffers: local hit=4
Total runtime: 0.027 ms
