PostgreSQL 慢查询，限制为 1 并按不需要的 where 条件排序

Question

我有一张表accounts 和索引

accounts {
    id  text
    num_id  bigint
    pid text
    fid text
    created_at  timestamp with time zone
    updated_at  timestamp with time zone
}

CREATE UNIQUE INDEX accounts_pkey ON public.accounts USING btree (id)
CREATE INDEX fid_idx ON public.accounts USING btree (fid)
CREATE INDEX idx_accounts_pid_fid ON public.accounts USING btree (pid, fid)

而且这个查询很慢

explain analyse SELECT * FROM accounts
WHERE pid = 'hd' AND fid = '123'
ORDER BY  id ASC
LIMIT 1;

Limit  (cost=0.56..3173.34 rows=1 width=123) (actual time=49389.351..49389.351 rows=0 loops=1)
  ->  Index Scan using accounts_pkey on accounts  (cost=0.56..5022497.13 rows=1583 width=123) (actual time=49389.350..49389.350 rows=0 loops=1)
        Filter: ((pid = 'hd'::text) AND (fid = '123'::text))
        Rows Removed by Filter: 56821193
Planning time: 0.094 ms
Execution time: 49389.368 ms

根据这个answer，可以通过添加不需要的where条件pid和fid来解决

explain analyse SELECT * FROM accounts
WHERE pid = 'hd' AND fid = '123'
ORDER BY  id ASC, pid, fid
LIMIT 1;

但是，它不起作用

Limit  (cost=0.56..3173.37 rows=1 width=123) (actual time=49495.236..49495.236 rows=0 loops=1)
  ->  Index Scan using accounts_pkey on accounts  (cost=0.56..5022556.07 rows=1583 width=123) (actual time=49495.234..49495.234 rows=0 loops=1)
        Filter: ((pid = 'hd'::text) AND (fid = '123'::text))
        Rows Removed by Filter: 56821555
Planning time: 0.096 ms
Execution time: 49495.253 ms

我是不是不见了？

PostgreSQL 版本：9.6.8

Answer 1

从您的 cmets 来看，以下查询实际上非常高效：

SELECT *
FROM accounts
ORDER BY id
LIMIT 1;

之所以表现良好，是因为LIMIT 和ORDER BY 这一步是Postgres 在SELECT 之前唯一需要做的事情，而accounts_pkey 唯一索引可以在这里轻松扫描。其实Postgres只需要找到最低的id值，然后再参考聚集索引覆盖SELECT *即可。

但是，您问题中的查询有点不同：

SELECT *
FROM accounts
WHERE pid = 'hd' AND fid = '123'
ORDER BY id ASC
LIMIT 1;

在这种情况下，Postgres 选择扫描整个accounts_pkey 索引，从与您的WHERE 子句对应的过滤步骤开始。因为accounts_pkey 只覆盖id 列，所以Postgres 必须回溯到聚集索引来查找pid 和fid 的值。理想情况下，Postgres 会从最低的 id 值开始，然后沿着索引向下走，直到找到 pid 和 fid 值上的第一个匹配项。无论 Postgres 决定做什么，以下覆盖索引都可以在这里提供帮助：

CREATE INDEX idx_accounts_cover ON public.accounts USING btree (pid, fid, id);

鉴于现在可以使用上述索引轻松删除近 600 万条记录，id 上的剩余 LIMIT/ORDER BY 操作可能更容易接受。而且由于这个索引也涵盖了id，所以 Postgres 只需要在查询的最后一次回溯到聚集索引。