Postgres select 查詢在使用 JDBC 時運行緩慢，但在 PSQL 中從同一服務器運行時運行速度很快

Question

我有以下非常簡單的查詢，我正在使用 JDBC 運行，這需要花費過多的時間來運行。 該數據庫是 AWS RDS 服務器。 rt2 表有大約 600K 條目，CM2 表大約有 300K。 該查詢返回 11230 行。

SELECT cm2.target 
from sysmgmt.sys_root rt2 
   join cmgmt.member cm2 on cm2.cmid = rt2.cmid and cm2.version=rt2.work_version_id 
where rt2.tid=1001 
  and rt2.proj='d791194b-f2b7-42a7-aba7-f879e052e59d'::uuid 
  and rt2.deleted = false 
  and cm2.tid=1001 and cm2.proj = 'd791194b-f2b7-42a7-aba7-f879e052e59d'::uuid;

但是，當我使用 JDBC 調用運行此查詢時，它需要 40 秒。 如果我在同一台機器上的 PSQL 命令行中運行這個完全相同的查詢，它幾乎是瞬時的。

運行 EXPLAIN ANALYZE 顯示以下計划。

Nested Loop  (cost=0.85..7.77 rows=1 width=176) (actual time=0.030..36.067 rows=11230 loops=1)
->  Index Scan using m_cell_tid_proj_version_idx on member cm2  (cost=0.42..3.32 rows=1 width=197) (actual time=0.020..2.988 rows=11230 loops=1)
    Index Cond: ((tid = '1001'::numeric) AND (proj = 'ed1a7c79-a3a1-4d8e-815b-0fbbcbd7bf4b'::uuid))
->  Index Scan using sys_root_cmid_workversion_idx on sys_root rt2  (cost=0.42..4.45 rows=1 width=21) (actual time=0.002..0.002 rows=1 loops=11230)
    Index Cond: ((cmid = cm2.cmid) AND (work_version_id = cm2.version))
    Filter: ((NOT deleted) AND (tid = '1001'::numeric) AND (proj = 'ed1a7c79-a3a1-4d8e-815b-0fbbcbd7bf4b'::uuid))
Planning Time: 0.374 ms
Execution Time: 36.499 ms

有些事情我試圖加快速度。

• 重新排列查詢
• 添加匹配更好的索引
• 更改填充因子（似乎沒有任何效果）
• 真空

這些似乎都沒有任何效果。 java 代碼非常簡單，運行查詢然后迭代結果。 計時是在 executeQuery 之前和之后進行的。

  Took :[40644.067138] Comment:found 11230 SQL Query:[SELECT cm2.target from sysmgmt.sys_root rt2 join mgmt.member cm2 on cm2.cmid = rt2.cmid and cm2.version=rt2.work_version_id where rt2.tid=1001 and rt2.proj='ed1a7c79-a3a1-4d8e-815b-0fbbcbd7bf4b'::uuid and cm2.tid=1001 and cm2.proj = 'ed1a7c79-a3a1-4d8e-815b-0fbbcbd7bf4b'::uuid and rt2.deleted = false]

大約有 5 到 10 個其他查詢在同一事務中運行，其他查詢是否有可能在到達該查詢時導致下游出現問題？

如果有人對可能出現的問題有任何想法，我將不勝感激。

Answer 1

事實證明，在活動上下文中運行時，解釋分析計划是不同的。 打開 auto_explain 參數並將其記錄到 postgres 日志文件表明該計划與我將其作為獨立請求運行時不同。 然后問題變成了“如何讓它做正確的事情？”。 答案是將 default_statistics_target 從 100 提高到 200 並在數據庫上運行 ANALYZE。 我還重新排列了連接表的順序。 在做這兩個方面，問題已經消失了（希望是好的）。 這個wiki https://wiki.postgresql.org/wiki/Performance_Optimization也被證明是一個很好的資源。