如果我有类似的东西：
CREATE INDEX idx_myTable_field_x
ON myTable
USING btree (field_x);
SELECT COUNT(field_x), field_x FROM myTable GROUP BY field_x ORDER BY field_x;
想象myTable 与500,000 rows 和大部分field_x 值是唯一的。
由于我不使用任何WHERE 子句，创建的索引对我的查询有任何影响吗？
编辑：我问这个问题是因为在创建索引之前和之后的查询时间之间没有任何相关差异；它们总是需要大约 8 秒（这当然是太多的时间了！）。这是预期的行为吗？
【问题讨论】：
标签： sql postgresql indexing
索引在这里无济于事，因为无论如何您都在读取整个表，首先进入索引是没有用的（PostgreSQL 还没有仅索引扫描）
因为索引中的几乎所有值都是唯一的，所以无论如何它在这种情况下并没有真正的帮助。索引查找（包括对其他 DBMS 的索引扫描）往往对查找少量行很有帮助。
索引可能用于排序的可能性很小，但我对此表示怀疑。
如果您查看EXPLAIN ANALYZE VERBOSE 的输出，您可以看到排序是在内存中完成的，还是（由于结果的大小）是在磁盘上完成的。
如果排序是在磁盘上完成的，您可以通过增加 work_mem 来加快查询速度 - 无论是全局还是仅针对您的会话。
【讨论】：
SET work_mem = ...）。但是您应该首先检查排序是否确实在磁盘上完成
Sort Method: external merge Disk: 4984kB 上完成；但是，在SET work_mem = '6000' 之后，查询似乎和以前一样长，8 秒，这是不可接受的:-(...
work_mem = '6000' 您实际上减少了它。也许它需要的不仅仅是日志文件中显示的内容。您应该尝试使用work_mem = '20MB' 之类的方法来超越默认设置。
1MB）在将其设置为20MB之后，查询时间实际上减少了一点（虽然还不够）；谢谢，你帮了很多忙！ :)
由于field_x 是您的查询中引用的唯一列，因此您的索引covers 应该可以帮助您避免查找myTable 的实际行。
编辑：正如下面的评论讨论中所指出的，虽然这个答案对大多数 RDBMS 实现都有效，但它不适用于 postgresql。
【讨论】：
-> Sort (cost=46675.90..47425.90 rows=300000 width=7) 排序键：field_x | -> Seq Scan on mytable (cost=0.00..15282.00 rows=300000 width=7)
应该使用索引。如果您想查看索引是如何使用（或不使用）的，查询的执行计划是查看数据库决定做什么的好地方。在您的情况下，您应该执行以下操作：
explain SELECT COUNT(field_x), field_x FROM myTable GROUP BY field_x ORDER BY field_x;
有关您看到的所有输出的更多信息，请参阅 postgres 文档：http://www.postgresql.org/docs/8.4/static/sql-explain.html
还有：http://wiki.postgresql.org/wiki/Image:Explaining_EXPLAIN.pdf，更深入一点。
【讨论】：
EXPLAIN 输出...