Postgres表選擇查詢太慢

我有一個gps跟蹤應用程序。它有一個名爲gps_vehicle_data的表，其中傳入的gps數據經常存儲。我經常查詢這個表格來處理它，因爲它只包含原始數據。最近，我目睹了執行陳述中陳述的長時間拖延。以下是EXPLAIN的結果。我也試着在VACUUM &上粘貼下面的結果。可能是什麼原因？Postgres表選擇查詢太慢

EXPLAIN (ANALYZE, BUFFERS) select * from gps_vehicle_data; 

                  QUERY PLAN                
--------------------------------------------------------------------------------------------------------------------------------- 
Seq Scan on gps_vehicle_data (cost=0.00..130818.81 rows=1400881 width=1483) (actual time=209.129..62488.822 rows=9635 loops=1) 
    Buffers: shared hit=13132 read=103678 dirtied=67 written=25 
Planning time: 0.050 ms 
Execution time: 62500.850 ms

VACUUM OUTPUT。

VACUUM (VERBOSE,ANALYSE) gps_vehicle_data; 
INFO: vacuuming "public.gps_vehicle_data" 
INFO: index "gps_vehicle_data_pkey" now contains 1398939 row versions in 10509 pages 
DETAIL: 0 index row versions were removed. 
0 index pages have been deleted, 0 are currently reusable. 
CPU 0.07s/0.09u sec elapsed 9.38 sec. 
INFO: index "gps_vehicle_data_status_idx" now contains 1398939 row versions in 4311 pages 
DETAIL: 0 index row versions were removed. 
0 index pages have been deleted, 0 are currently reusable. 
CPU 0.03s/0.04u sec elapsed 4.50 sec. 
INFO: index "gps_vehicle_data_url_data_idx" now contains 1399004 row versions in 98928 pages 
DETAIL: 0 index row versions were removed. 
0 index pages have been deleted, 0 are currently reusable. 
CPU 0.76s/0.88u sec elapsed 82.74 sec. 
INFO: index "gps_vehicle_data_createdon_idx" now contains 1399007 row versions in 3946 pages 
DETAIL: 0 index row versions were removed. 
0 index pages have been deleted, 0 are currently reusable. 
CPU 0.00s/0.02u sec elapsed 1.92 sec. 
INFO: "gps_vehicle_data": found 0 removable, 1402484 nonremovable row versions in 116884 out of 116884 pages 
DETAIL: 1401490 dead row versions cannot be removed yet. 
There were 143431 unused item pointers. 
Skipped 0 pages due to buffer pins. 
0 pages are entirely empty. 
CPU 1.70s/2.38u sec elapsed 200.61 sec. 
INFO: vacuuming "pg_toast.pg_toast_17296" 
INFO: index "pg_toast_17296_index" now contains 0 row versions in 1 pages 
DETAIL: 0 index row versions were removed. 
0 index pages have been deleted, 0 are currently reusable. 
CPU 0.00s/0.00u sec elapsed 0.01 sec. 
INFO: "pg_toast_17296": found 0 removable, 0 nonremovable row versions in 0 out of 0 pages 
DETAIL: 0 dead row versions cannot be removed yet. 
There were 0 unused item pointers. 
Skipped 0 pages due to buffer pins. 
0 pages are entirely empty. 
CPU 0.00s/0.00u sec elapsed 0.01 sec. 
INFO: analyzing "public.gps_vehicle_data" 
INFO: "gps_vehicle_data": scanned 30000 of 116884 pages, containing 335 live rows and 359656 dead rows; 335 rows in sample, 1042851 estimated total rows 
VACUUM

來源

2016-08-03 Vignesh Bhaskar

您的表格包含無法清理的「**行**」**（「1401490死行版本無法刪除」）。最有可能的原因是，你的連接在事務中處於空閒狀態，無法清理舊行。 –

你讀100000塊得到一些10000行，這意味着你的表幾乎完全由虛無（它是從表膨脹痛苦）。

該表必須包含更多的數據在某些時候，其中大部分已被刪除，從而導致膨脹。

正如@a_horse_with_no_name提到的那樣，由於有一些舊事務阻塞了它們，所以你的某些行不能被回收，但是當VACUUM會釋放死行時，它不會重新組織表以擺脫膨脹。

在這種情況下，正確的解決方案是使用VACUUM (FULL, ANALYZE) gps_vehicle_data（ANALYZE僅用於衡量表格，因爲它看起來像表格統計信息已關閉），這將重新組織表格。但是，請注意，當VACUUM (FULL)正在運行時，表格的所有訪問都被阻止。

來源

2016-08-03 10:20:54

非常感謝。我關閉了所有連接到db＆ran VACUUM（VERBOZE，ANALYZE）的應用程序服務器並刪除了空閒的行。現在查詢速度更快。我也會在維修時間內嘗試VACUUM（FULL，ANALYZE）。 –

請勿定期運行'VACUUM（FULL）'。通常情況下，除非您進行批量刪除，否則表格不應該變得臃腫。 –

是的，一旦原始數據被處理，我會進行批量刪除。在那種情況下沒問題，還是有問題？ –

Postgres表選擇查詢太慢

回答

相關問題