如何识别需要创建哪些索引答案

【问题标题】：how to ID which indexes need to be created如何识别需要创建哪些索引
【发布时间】：2018-08-07 14:57:47
【问题描述】：

背景

我正在尝试查找可以使用索引的表。程序员抱怨某些表查询非常慢。

我在 stackoverflow 上找到了这个查询：

SELECT   schemaname, relname, seq_scan, seq_tup_read,
           idx_scan, seq_tup_read / seq_scan AS avg
FROM    pg_stat_user_tables
WHERE   seq_scan > 0
ORDER BY seq_tup_read DESC
LIMIT 20;

我尝试在我的数据库上运行，果然，出现了我们的程序员抱怨的表之一：

 schemaname |        relname         | seq_scan | seq_tup_read | idx_scan |  avg
------------+------------------------+----------+--------------+----------+-------
 public     | widgets                |      511 |     22834898 |        3 | 44686

根据我阅读的内容，如果您的表的 seq-scans 比 idx-scans 多，那么这是一个可以使用更多索引的表的良好指标。

问题

我的下一个补救问题是我如何知道要索引哪一列？

我查询了当前存在哪些索引：

testdb=# select * from pg_indexes where tablename='widgets';
 schemaname | tablename |   indexname   | tablespace |                            indexdef
------------+-----------+---------------+------------+----------------------------------------------------------------
 public     | widgets| widgets_pkey |            | CREATE UNIQUE INDEX widgets_pkey ON widgets USING btree (id)
(1 row)

这就是表格的一般外观：

testdb=# \d widgets
                                    Table "public.widgets"
  Column  |            Type             |                       Modifiers
----------+-----------------------------+-------------------------------------------------------
 id       | integer                     | not null default nextval('widgets_id_seq'::regclass)
 id_ts    | timestamp without time zone | default now()
 status   | character varying(32)       |
 class    | character varying(16)       |
 from     | character varying(32)       |
 to       | character varying(32)       |
 start_ts | integer                     |
 end_ts   | integer                     |
 elapsed  | integer                     |
Indexes:
    "widgets_pkey" PRIMARY KEY, btree (id)

任何建议将不胜感激。

【问题讨论】：

问题是创建最适合您的特定用例的索引。因此，需要知道您正在运行哪些使用该表的查询
我检查了它，所有针对该表的查询都使用 WHERE 子句中的“id”字段。
只有 id 就可以了？没有其他领域？除了id肯定应该还有其他条件
没有。肯定只是身份证。但我认为问题可能更多与硬件相关......或RAM。因为我在 sql 方面看不到任何确凿证据....????

标签： database postgresql indexing postgresql-9.4

【解决方案1】：

使用pg_stat_statements 找出导致顺序扫描的查询。

您必须将其添加到 shared_preload_libraries 并重新启动 PostgreSQL。然后使用

创建pg_stat_statements 视图

CREATE EXTENSION pg_stat_statements;

然后等到收集了一些工作负载并查询视图。您可以使用您的表名 (WHERE query ILIKE '%table_name%') 过滤语句，并首先获取运行时间最长的语句。

这应该会显示导致顺序扫描的查询。

【讨论】：