我有一個notification包含 2 列的表：（id主鍵）和entity（js??onb）
SELECT *
FROM notification
WHERE entity -> 'name' = 'Hello World'
ORDER by id DESC
執行速度比沒有以下的相同查詢快得多ORDER BY：
SELECT *
FROM notification
WHERE entity -> 'name' = 'Hello World'
沒有物體 -> 'name' 索引。
我注意到，第一個查詢使用索引掃描，而第二個查詢 - 序列掃描。執行時間的差異：60 秒對 0.5 秒。
- 表格行數：16696
- 回傳結果：95行
怎么解釋？
UPD。EXPLAIN (ANALYZE, BUFFERS) 第一個查詢：
Index Scan using notification_pkey on notification (cost=0.41..233277.12 rows=1 width=264) (actual time=480.582..583.623 rows=95 loops=1)
Filter: ((entity ->> 'name'::text) = 'Hello World'::text)
Rows Removed by Filter: 16606
Buffers: shared hit=96807
Planning Time: 0.211 ms
Execution Time: 583.826 ms
對于第二個查詢：
Seq Scan on notification (cost=0.00..502145.78 rows=1 width=264) (actual time=49675.453..60160.280 rows=95 loops=1)
Filter: ((entity ->> 'name'::text) = 'Hello World'::text)
Rows Removed by Filter: 16606
Buffers: shared hit=91608 read=497908
I/O Timings: read=55311.842
Planning Time: 0.112 ms
Execution Time: 60160.309 ms
UPD 2. 我在桌子上執行了 VACUUM ANALYZE，但它并沒有提高性能。
uj5u.com熱心網友回復：
您的表似乎已經膨脹到包含近 500000 個 8kB 空塊的程度。由于在索引掃描期間不會讀取這些內容，因此索引掃描實際上比順序掃描快。
您應該找到并解決導致膨脹的問題，然后花時間重新組織表
VACUUM (FULL) notification;
轉載請註明出處，本文鏈接：https://www.uj5u.com/shujuku/459254.html
標籤：sql 数据库 PostgreSQL 表现 索引
上一篇：為什么一個代表比另一個快？