Postgres的，簡單查詢不使用索引

我有一個表稱爲message_attachments有1931964行。

有我在該表中搜索的一個關鍵，那就是message_id。

我也總是包含deleted_at是NULL語句（如軟刪除）。

有一個指數發佈：

CREATE INDEX message_attachments_message_id_idx 
    ON message_attachments (message_id) 
WHERE deleted_at IS NULL;

所以應該直接匹配這個查詢：

EXPLAIN ANALYZE 
select * 
from "message_attachments" 
where "deleted_at" is null 
    and "message_id" = 33998052;

但由此產生的查詢計劃是這樣的：

Seq Scan on message_attachments (cost=0.00..69239.91 rows=4 width=149) (actual time=1667.850..1667.850 rows=0 loops=1) 
    Filter: ((deleted_at IS NULL) AND (message_id = 33998052)) 
    Rows Removed by Filter: 1931896 
Planning time: 0.114 ms 
Execution time: 1667.885 ms

我米使用這樣的指數通過我的數據庫，但不知何故，它似乎不喜歡它在該具體的ta BLE。

關於基數，最多隻有5列具有相同的值。

此外，在該表上運行ANALYZE和VACUUM ANALYZE。

編輯1

SET enable_seqscan to off

SET enable_seqscan to off; EXPLAIN ANALYZE select * from "message_attachments" where "deleted_at" is null and "message_id" = 33998052; 
SET 
                      QUERY PLAN 
----------------------------------------------------------------------------------------------------------------------------------------------------------------- 
Bitmap Heap Scan on message_attachments (cost=36111.83..105378.49 rows=4 width=149) (actual time=2343.361..2343.361 rows=0 loops=1) 
    Recheck Cond: (deleted_at IS NULL) 
    Filter: (message_id = 33998052) 
    Rows Removed by Filter: 1932233 
    Heap Blocks: exact=45086 
    -> Bitmap Index Scan on message_attachments_deleted_at_index (cost=0.00..36111.82 rows=1934453 width=0) (actual time=789.836..789.836 rows=1933784 loops=1) 
     Index Cond: (deleted_at IS NULL) 
Planning time: 0.098 ms 
Execution time: 2343.425 ms

這將是對上表中的第二個索引，它看起來像現在運行：（和絕對不能使用）

CREATE INDEX message_attachments_deleted_at_index ON message_attachments USING btree (deleted_at)

編輯2

\d+ message_attachments 
                 Table "public.message_attachments" 
    Column |   Type    |       Modifiers        | Storage | Stats target | Description 
------------+-----------------------------+------------------------------------------------------------------+----------+--------------+------------- 
id   | bigint      | not null default nextval('message_attachments_id_seq'::regclass) | plain |    | 
created_at | timestamp without time zone | not null               | plain |    | 
updated_at | timestamp without time zone | not null               | plain |    | 
deleted_at | timestamp without time zone |                 | plain |    | 
name  | character varying(255)  | not null               | extended |    | 
filename | character varying(255)  | not null               | extended |    | 
content | bytea      |                 | extended |    | 
hash  | character varying(255)  | not null               | extended |    | 
mime  | character varying(255)  | not null               | extended |    | 
size  | bigint      | not null               | plain |    | 
message_id | bigint      | not null               | plain |    | 
Indexes: 
    "message_attachments_pkey" PRIMARY KEY, btree (id) 
    "message_attachments_deleted_at_index" btree (deleted_at) 
    "message_attachments_message_id_idx" btree (message_id) WHERE deleted_at IS NULL 
Foreign-key constraints: 
    "message_attachments_message_id_foreign" FOREIGN KEY (message_id) REFERENCES messages(id)

EDIT3

完全一樣的一個熱備用主機上的行爲。（這是up2date的）

Edit4

select seq_scan,seq_tup_read,idx_scan,idx_tup_fetch,n_live_tup,pg_stat_all_tables.n_dead_tup,last_analyze,pg_stat_all_tables.analyze_count,pg_stat_all_tables.last_autoanalyze from pg_stat_all_tables where relname = 'message_attachments'; 
seq_scan | seq_tup_read | idx_scan | idx_tup_fetch | n_live_tup | n_dead_tup |   last_analyze   | analyze_count |  last_autoanalyze 
----------+----------------+----------+---------------+------------+------------+-------------------------------+---------------+------------------------------- 
18728036 | 26379554229720 | 1475541 |  808566894 | 1934435 |  28052 | 2017-04-12 09:48:34.638184+02 |   68 | 2017-02-02 18:41:05.902214+01 

select * from pg_stat_all_indexes where relname = 'message_attachments'; 
relid | indexrelid | schemaname |  relname  |    indexrelname    | idx_scan | idx_tup_read | idx_tup_fetch 
--------+------------+------------+---------------------+--------------------------------------+----------+--------------+--------------- 
113645 |  113652 | public  | message_attachments | message_attachments_pkey    | 1475563 | 804751648 |  802770401 
113645 |  113659 | public  | message_attachments | message_attachments_deleted_at_index |  3 |  5801165 |    0 
113645 | 20954507 | public  | message_attachments | message_attachments_message_id_idx |  0 |   0 |    0

來源

2017-04-12 Thomas Rosenstein

嘗試'SET ENABLE_SEQSCAN到off「並再次運行分析以檢查費用 –

您正在使用哪個Postgres版本？你真的確定你分析過這張桌子嗎？ Postgres估計只有4行（當表有近200萬個時）似乎表明統計數據不是最新的。 –

@a_horse_with_no_name明確地是奇怪的！我使用的是9.5，而在pg_class中，它告訴我有1934020個元組，這4行的估計值來自哪裏？我確實運行了VACUUM ANALYZE message_attachments，並且ANALYZE message_attachments –

好吧，我只是解決了這個。

我們不知何故有針對的是PHP死亡，但從來沒有退出上的Postgres從幾天前的過程中查詢吊鎖。

所以，大家expiriencing同樣的問題，請檢查你鎖：

SELECT relation::regclass, * FROM pg_locks WHERE NOT GRANTED;

還有，如果有任何連接打開，因爲前幾天：

select * from pg_stat_activity order by query_start limit 10;

來源

2017-04-12 08:55:21

我是隻是要問，如果你有任何「閒置交易」會話... –

明確需要添加一些監控現在.. –

你有索引鎖，而不是表？並且你可以重建那個索引，但是不能用於select？.. –

Postgres的，簡單查詢不使用索引

回答

相關問題