Çok basit bir örnek - bir tablo, bir dizin, bir sorgu:
CREATE TABLE book
(
id bigserial NOT NULL,
"year" integer,
-- other columns...
);
CREATE INDEX book_year_idx ON book (year)
EXPLAIN
SELECT *
FROM book b
WHERE b.year > 2009
bana verir:
Seq Scan on book b (cost=0.00..25663.80 rows=105425 width=622)
Filter: (year > 2009)
Bunun yerine neden dizin taraması YAPMAZ? Neyi kaçırıyorum?
Yanıtlar:
SELECT, tablodaki tüm satırların yaklaşık% 5-10'undan fazlasını döndürürse, sıralı tarama, dizin taramasından çok daha hızlıdır.
Bunun nedeni, bir dizin taramasının her satır için birkaç GÇ işlemi gerektirmesidir (dizindeki satıra bakın, ardından yığından satırı alın). Sıralı bir tarama, her satır için yalnızca tek bir GÇ gerektirirken - veya diskteki bir blok (sayfa) birden fazla satır içerdiğinden daha az, böylece tek bir GÇ işlemiyle birden fazla satır getirilebilir.
Btw: Bu, diğer DBMS için de geçerlidir - "yalnızca dizin taramaları" gibi bazı optimizasyonlar bir kenara alınır (ancak bir SELECT * için böyle bir DBMS'nin "yalnızca dizin taraması" için gitmesi pek olası değildir)
Eğer mı ANALİZ tablo / veritabanı? Peki ya istatistikler ? Yılın> 2009 olduğu birçok kayıt olduğunda, sıralı bir tarama, dizin taramasından daha hızlı olabilir.
İndeks taramasında, bir satırdan diğerine bir sonraki fiziksel bloğu okumaktan (sıralı taramada) 1000 kat daha yavaş olan kafa atlamalarını okuyun.
Dolayısıyla, (alınacak kayıt sayısı * 1000) toplam kayıt sayısından azsa, indeks taraması daha iyi sonuç verecektir.
@a_horse_with_no_name bunu oldukça iyi açıkladı. Ayrıca, gerçekten bir dizin taraması kullanmak istiyorsanız, genellikle where cümlesinde sınırlı aralıklar kullanmalısınız. örneğin - yıl> 2019 ve yıl <2020.
Çoğu zaman istatistikleri bir tabloda güncellenmez ve kısıtlamalar nedeniyle bunu yapmak mümkün olmayabilir. Bu durumda, optimizer> 2019 yılında kaç satır alması gerektiğini bilemez. Böylece tam bilgi yerine sıralı bir tarama seçer. Sınırlı bölümler çoğu zaman sorunu çözecektir.