我有四张桌子。
Entry_Branch Association（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)
员工（to_emp_id） - ＆gt;我在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） - ＆gt; 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 Scan我不知道为什么？
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表进行顺序扫描。 任何改进查询的建议。
答案 0 :(得分：0)
您是否定期在数据库上运行ANALYZE命令？
我曾经有同样的问题，运行后分析它就消失了。
答案 1 :(得分：0)
可能索引po_screntry_branch_assoc_pkey失败。删除此索引，然后重试explain analyze。
可能PRIMARY KEY更重要的是INDEX和使用它的计划者。