Question

我有一个包含几百万行的表，其中经常插入行，甚至更经常地获取行。

行插入时间并不重要，但提取时间是因为它正在为网站服务。因此，我created already an index, that helped to fetch much faster。

查询非常简单，不包含JOIN。

SELECT次查询会出现问题。一旦用户执行搜索，相同的SELECT查询将每隔几秒运行一次以检查新行或更新的行。但是，SELECT查询第一次运行50秒并且之后相同的查询不到1秒就不奇怪了。

这让我觉得问题本身不是SELECT语句，而是其他问题。

表格是：

CREATE TABLE all_legs (
                carrier TEXT,
                dep_hub TEXT,
                arr_hub TEXT,
                dep_dt TIMESTAMP WITH TIME ZONE,
                arr_dt TIMESTAMP WITH TIME ZONE,
                price_ct INTEGER,
                ... 5 more cols ...,
                PRIMARY KEY (carrier, dep_hub, arr_hub, dep_dt, arr_dt, ...3 other cols...)
                )

INDEX是：

CREATE INDEX IF NOT EXISTS fetch_index ON all_legs(dep_dt, LEFT(dep_hub::text, 6), LEFT(arr_hub::text, 6));

SELECT查询：

SELECT * FROM all_legs
                    WHERE dep_dt >= %s
                    AND dep_dt < %s
                    AND (LEFT(dep_hub::text, 6) = %s AND LEFT(arr_hub::text, 6) = %s)

这种情况并不总是发生，因此难以复制。这里有一个来自我本地数据库的EXPLAIN语句，它的数据少于Heroku上的数据并且运行速度非常快：

Index Scan using tz_idx on all_legs  (cost=0.41..111184.33 rows=1 width=695) (actual time=128.100..136.690 rows=20 loops=1)
  Index Cond: (("left"(dep_hub, 6) = 'ES-PMI'::text) AND ("left"(arr_hub, 6) = 'ES-MAD'::text))
  Filter: ((dep_dt)::date = '2018-01-19'::date)
  Rows Removed by Filter: 271
Planning time: 3.798 ms
Execution time: 138.525 ms

为什么第一次慢得多，如何减少第一次查询的运行时间？

Answer 1

查询和索引中的LEFT函数可能会增加不必要的复杂性;你可以使用通配符匹配LIKE语句来获得相同的东西。

SELECT * FROM all_legs
WHERE dep_dt >= '2018-01-19'
AND dep_dt < '2018-01-20'
AND dep_hub LIKE 'ES-PMI%'
AND arr_hub LIKE 'ES-MAD%'

在最后两个参数的末尾添加%。

有了这个，您还应该能够通过删除涉及LEFT函数的索引来加速查询，并且只需正常索引列。

Answer 2

挤出单列（dep_hub）
如果您的{dep_hub，arr_hub}都引用同一个域，则必须稍微更改一下
您还必须重新定义主键
和[可能]在挤出表上添加一些功能索引

    -- [empty] table to contain the "squeezed out" domain
CREATE TABLE dep_hub
    ( id SERIAL NOT NULL PRIMARY KEY
    ,  dep_hub varchar
    , UNIQUE (dep_hub)
    );

   -- This is done in the chained insert/update
-- INSERT INTO dep_hub(dep_hub)
-- SELECT DISTINCT dep_hub
-- FROM all_legs ;


    -- an index may speedup the final update
    -- (the index will be dropped automatically
    -- once the column is dropped)
CREATE INDEX ON all_legs (dep_hub);

    -- The original table needs a "link" to the new table
ALTER TABLE all_legs
    ADD column dep_hub_id INTEGER -- NOT NULL
    REFERENCES dep_hub(id)
    ;

    -- FK constraints are helped a lot by a supportive index.
CREATE INDEX all_legs_dep_hub_fk ON all_legs (dep_hub_id);

    -- Chained query to:
    -- * populate the domain table
    -- * initialize the FK column in the original table
WITH src AS (
    INSERT INTO dep_hub(dep_hub)
    SELECT DISTINCT a.dep_hub
    FROM all_legs a
    RETURNING *
    )
UPDATE all_legs dst
SET  dep_hub_id = src.id
FROM src
WHERE src.dep_hub = dst.dep_hub
    ;

    -- Now that we have the FK pointing to the new table,
    -- we can drop the redundant column.
ALTER TABLE all_legs DROP COLUMN dep_hub;

减少SQL中的提取时间（索引已经完成）

2 个答案: