sql - 类似服务器上的 PostgreSQL 不同查询计划

Question

在具有相同数据库的类似 Amazon RDS PostgreSQL 服务器版本 9.6.11 上，我为一个 SQL 查询获得了不同的执行计划。

我尝试重新创建索引并运行 ANALYZE 和 VACUUM。没有任何帮助。

我的查询:

SELECT "users_employee"."id",
       (
           SELECT U0."created"
           FROM "surveys_surveyrequest" U0
           WHERE (U0."confirmed" IS NULL
                  AND U0."skipped" IS NULL
                  AND U0."from_member_id" = ("users_employee"."id"))
           ORDER BY U0."created" ASC
           LIMIT 1) AS "earliest_request_date"
FROM "users_employee"
ORDER BY "users_employee"."id" ASC;

问题表信息:

 create table surveys_surveyrequest
(
    id integer default nextval('public.surveys_surveyrequest_id_seq'::regclass) not null
        constraint surveys_surveyrequest_pkey
            primary key,
    created timestamp with time zone not null,
    skipped timestamp with time zone,
    from_member_id integer
        constraint surveys_surveyreques_from_member_id_81f0e82e_fk_users_emp
            references users_employee
                deferrable initially deferred,
    confirmed timestamp with time zone
);

create index surveys_sur_confirm_48bfa6_idx
    on surveys_surveyrequest (confirmed);

create index surveys_sur_created_099976_idx
    on surveys_surveyrequest (created);


create index surveys_surveyrequest_70b76ad7
    on surveys_surveyrequest (from_member_id);

计划:答:

                                                                                    QUERY PLAN
-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
 Index Only Scan using auth_user_pkey on users_employee  (cost=0.28..991903.69 rows=1478 width=12) (actual time=139.054..195486.465 rows=1478 loops=1)
   Heap Fetches: 51
   Buffers: shared hit=296637323
   SubPlan 1
     ->  Limit  (cost=0.42..671.07 rows=1 width=8) (actual time=132.258..132.259 rows=1 loops=1478)
           Buffers: shared hit=296637288
           ->  Index Scan using surveys_sur_created_099976_idx on surveys_surveyrequest u0  (cost=0.42..24143.63 rows=36 width=8) (actual time=132.256..132.256 rows=1 loops=1478)
                 Filter: ((confirmed IS NULL) AND (skipped IS NULL) AND (from_member_id = users_employee.id))
                 Rows Removed by Filter: 405780
                 Buffers: shared hit=296637288
 Planning time: 0.188 ms
 Execution time: 195487.356 ms
(12 rows)

乙:

                                                                                  QUERY PLAN
------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
 Index Only Scan using auth_user_pkey on users_employee  (cost=0.28..886476.74 rows=1578 width=12) (actual time=0.977..1043.414 rows=1578 loops=1)
   Heap Fetches: 0
   Buffers: shared hit=98270 read=8
   SubPlan 1
     ->  Limit  (cost=561.74..561.74 rows=1 width=8) (actual time=0.658..0.659 rows=1 loops=1578)
           Buffers: shared hit=98266 read=5
           ->  Sort  (cost=561.74..561.79 rows=22 width=8) (actual time=0.658..0.658 rows=1 loops=1578)
                 Sort Key: u0.created
                 Sort Method: quicksort  Memory: 25kB
                 Buffers: shared hit=98266 read=5
                 ->  Bitmap Heap Scan on surveys_surveyrequest u0  (cost=474.19..561.63 rows=22 width=8) (actual time=0.646..0.652 rows=13 loops=1578)
                       Recheck Cond: ((from_member_id = users_employee.id) AND (confirmed IS NULL))
                       Filter: (skipped IS NULL)
                       Rows Removed by Filter: 3
                       Heap Blocks: exact=9707
                       Buffers: shared hit=98266 read=5
                       ->  BitmapAnd  (cost=474.19..474.19 rows=23 width=0) (actual time=0.641..0.641 rows=0 loops=1578)
                             Buffers: shared hit=88562 read=2
                             ->  Bitmap Index Scan on surveys_surveyrequest_70b76ad7  (cost=0.00..11.29 rows=382 width=0) (actual time=0.023..0.023 rows=258 loops=1578)
                                   Index Cond: (from_member_id = users_employee.id)
                                   Buffers: shared hit=5847 read=2
                             ->  Bitmap Index Scan on surveys_sur_confirm_48bfa6_idx  (cost=0.00..462.64 rows=24829 width=0) (actual time=0.826..0.826 rows=24756 loops=1165)
                                   Index Cond: (confirmed IS NULL)
                                   Buffers: shared hit=82715
 Planning time: 0.234 ms
 Execution time: 1043.680 ms
(26 rows)

Time: 1044,547 ms (00:01,045)

我希望生成相同的查询计划，但这并没有发生。可能是什么原因？Plan B如何实现执行力？

Answer 1

请检查两台服务器上的配置是否相同，所有索引是否存在且未标记为“无效”。

假设是这种情况，不同之处可能在于数据在两个数据库中的分布不同。请ANALYZE surveys_surveyrequest 并在两个数据库上运行以下命令:

SELECT correlation
FROM pg_stats
WHERE tablename = 'surveys_surveyrequest'
  AND attname = 'created';

我的猜测是该值在 A 上接近 1 或 -1，在 B 上接近 0。

That would explain为什么 PostgreSQL 更喜欢在 A 上进行索引扫描。计划 A 的问题是 PostgreSQL 必须扫描比预期更多的索引行，可能是因为与条件匹配的行都在索引中很远。

我想说你应该简单地禁用 surveys_sur_created_099976_idx 上的索引扫描，与

DROP INDEX surveys_sur_created_099976_idx;

或者(如果您出于其他目的需要索引)使用

ORDER BY U0."created" + INTERVAL '0 seconds'