使用聯接查詢性能問題（PostgreSQL）

Question

我有以下四個表。

Entry_Branch協會（to_entry_branch_assoc） ：索引已在其中

\d to_entry_branch_assoc
  Table "public.to_entry_branch_assoc"
      Column      |  Type   |  Modifiers   
------------------+---------+--------------
 toid_instan_branch | integer | not null
 toid_screntry      | integer | not null
 bl_is_optimized  | boolean | default true
Indexes:
    "po_screntry_branch_assoc_pkey" PRIMARY KEY, btree (id_instan_branch, id_screntry)
    "index_po_screntry_branch_assoc_id_screntry" btree (id_screntry)    

Employee（to_emp_id） ->我在toid_emp_id上有索引，這是主鍵。

\d to_emp_id
                                        Table "public.to_emp_id"
    Column     |          Type          |                           Modifiers                           
---------------+------------------------+---------------------------------------------------------------
 toid_emp_id     | integer                | not null default nextval('to_emp_toid_toid_emp_toid_seq'::regclass)
 tonu_toid_type    | integer                | not null
 tx_toid_string  | character varying(256) | not null
 toid_employee   | integer                | not null
 toid_enterprise | integer                | 
Indexes:
    "to_emp_toid_pkey" PRIMARY KEY, btree (toid_emp_id)

條目表（to_entry） -> toid_screntry的索引和其他索引。

\d to_entry
                                              Table "public.to_entry"
        Column         |           Type            |                             Modifiers                             
-----------------------+---------------------------+-------------------------------------------------------------------
 toid_screntry           | integer                   | not null default nextval('to_entry_toid_screntry_seq'::regclass)
 revision           | text                      | not null
 dt_submit_date        | date                      | not null
 tm_submit_time        | time(6) without time zone | not null
 tx_state              | character varying(256)    | not null
 tonu_loc_added          | integer                   | 
 tonu_loc_removed        | integer                   | 
 tonu_loc_total          | integer                   | 
 tx_comments           | text                      | 
 tonu_comment_flux       | integer                   | 
 tonu_comment_total      | integer                   | 
 tonu_cyclo_flux         | integer                   | 
 tonu_cyclo_total        | integer                   | 
 tonu_halstead_flux      | integer                   | 
 tonu_halstead_total     | integer                   | 
 tonu_filesize_flux      | integer                   | 
 tonu_filesize_total     | integer                   | 
 toid_emp_id             | integer                   | not null
 toid_scrfile            | integer                   | not null
 toid_infra_instan       | integer                   | not null
 bl_possible_copy      | boolean                   | default false
 tonu_nom_flux           | integer                   | 
 tonu_nom_total          | integer                   | 
 tonu_dac_flux           | integer                   | 
 tonu_dac_total          | integer                   | 
 tonu_fanout_flux        | integer                   | 
 tonu_fanout_total       | integer                   | 
 bl_is_result_of_merge | boolean                   | default false
 ts_committed_on       | timestamp with time zone  | 
 toid_commit_by          | integer                   | 
 ar_merged_revisions   | text[]                    | 
 ar_parents            | text[]                    | 
 ts_authored_on        | timestamp with time zone  | 
 tx_timezone_name      | text                      | 
 ar_adjustment_types   | boolean[]                 | 
 ar_adjustment_group   | integer[]                 | 
 ar_activity_exclusion | boolean[]                 | 
 is_activity_excluded  | boolean                   | default false
 toid_organization       | integer                   | 
Indexes:
    "to_entry_pkey" PRIMARY KEY, btree (toid_screntry)
    "index_to_entry_toid_commit_by" btree (toid_commit_by)
    "index_to_entry_toid_emp_id" btree (toid_emp_id)
    "index_to_entry_toid_infra_instan" btree (toid_infra_instan)
    "index_to_entry_toid_organization" btree (toid_organization)
    "index_to_entry_toid_scrfile" btree (toid_scrfile)
    "index_to_entry_revision" btree (revision)

另一個員工表（to_emp_id）：toid_emp_id的索引

\d to_emp_id
                                        Table "public.to_emp_id"
    Column     |          Type          |                           Modifiers                           
---------------+------------------------+---------------------------------------------------------------
 toid_emp_id     | integer                | not null default nextval('to_emp_toid_toid_emp_toid_seq'::regclass)
 tonu_toid_type    | integer                | not null
 tx_toid_string  | character varying(256) | not null
 toid_employee   | integer                | not null
 toid_enterprise | integer                | 
Indexes:
    "to_emp_toid_pkey" PRIMARY KEY, btree (toid_emp_id)

以下是我使用過的查詢，但是它在to_entry上使用了Seq掃描我不確定為什么？

EXPLAIN ANALYZE SELECT  toid_instan_branch,toid_employee
FROM to_entry_branch_assoc
JOIN to_entry ON to_entry_branch_assoc.toid_screntry = to_entry.toid_screntry
JOIN to_emp_id ON to_entry.toid_emp_id = to_emp_id.toid_emp_id
WHERE toid_instan_branch in(35347, 35348, 44812, 46244,123,12,12);

解釋計划的結果。

                                                                            QUERY PLAN                                                                                         
-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
 Hash Join  (cost=3404386.52..5144380.20 rows=732867 width=8) (actual time=496312.170..530727.862 rows=174563 loops=1)
   Hash Cond: (to_entry.toid_emp_id = to_emp_id.toid_emp_id)
   ->  Hash Join  (cost=3402188.89..5128441.31 rows=732867 width=8) (actual time=496252.231..530546.637 rows=174563 loops=1)
         Hash Cond: (to_entry_branch_assoc.toid_screntry = to_entry.toid_screntry)
         ->  Index Only Scan using to_entry_branch_assoc_pkey on to_entry_branch_assoc  (cost=0.58..1493856.40 rows=732867 width=8) (actual time=1.857..171.846 rows=174563 loops=1)
               Index Cond: (toid_instan_branch = ANY ('{35347,35348,44812,46244,123,12,12}'::integer[]))
               Heap Fetches: 174563
         ->  Hash  (cost=2661789.36..2661789.36 rows=45129036 width=8) (actual time=496236.872..496236.872 rows=45129087 loops=1)
               Buckets: 131072  Batches: 64  Memory Usage: 27622kB
               ->  Seq Scan on to_entry  (cost=0.00..2661789.36 rows=45129036 width=8) (actual time=1.241..478720.634 rows=45129087 loops=1)
   ->  Hash  (cost=1647.28..1647.28 rows=44028 width=8) (actual time=59.913..59.913 rows=44058 loops=1)
         Buckets: 8192  Batches: 1  Memory Usage: 1722kB
         ->  Seq Scan on to_emp_id  (cost=0.00..1647.28 rows=44028 width=8) (actual time=0.005..19.584 rows=44058 loops=1)
 Planning time: 0.537 ms
 Execution time: 530765.123 ms
(15 rows)

我在表上有所有可能的索引，但它正在對to_entry表進行順序掃描。 任何改善查詢的建議。

Answer 1

您是否在數據庫上定期運行ANALYZE命令？

我曾經有過同樣的問題，運行分析后消失了。

Answer 2

索引po_screntry_branch_assoc_pkey可能失敗。 刪除該索引，然后再嘗試explain analyze 。

可能PRIMARY KEY比INDEX和計划者使用它更重要。