Yanıtlar:
Dizine eklemeyi hemen en başından itibaren mi yoksa performans sorunu ortaya çıktığında mı?
Dizin oluşturma stratejisi, kullanım modelleri ortaya çıktıkça evrimleşme eğilimindedir. Bununla birlikte, ön tarafta uygulanabilecek stratejiler ve tasarım kılavuzları da vardır.
İyi bir kümeleme anahtarı seçin . Genellikle bir tabloya eklenen ekleme desenine bağlı olarak tasarım zamanında uygun kümelenmiş dizini belirleyebilirsiniz. Gelecekte bir değişiklik için zorlayıcı bir durum ortaya çıkarsa, öyle olsun.
Birincil ve diğer benzersiz kısıtlamalarınızı oluşturun . Bunlar, benzersiz dizinlerle uygulanacaktır.
Yabancı anahtarlarınızı ve ilişkili kümelenmemiş dizinleri oluşturun . Yabancı anahtarlar en sık başvurulan birleştirme sütunlarınızdır, bu nedenle onları başlangıçtan itibaren dizine ekleyin.
Oldukça seçici olan sorgular için dizinler oluşturun . Zaten bildiğiniz sorgu kalıpları için oldukça seçici olacaktır ve taramalar yerine aramalar kullanması muhtemeldir.
Yukarıdakilerin ötesinde, yeni endekslerin uygulanmasına kademeli ve bütüncül bir yaklaşım getirin. Bütünsel olarak, bir eklemeyi değerlendirirken tüm sorgular ve mevcut dizinler için potansiyel fayda ve etkiyi değerlendirmeyi kastediyorum.
SQL Server çevrelerinde nadir olmayan bir sorun, eksik dizin DMV'lerden ve SSMS ipuçlarından gelen rehberlik sonucu overindexing'dir. Bu araçların hiçbiri mevcut dizinleri değerlendirmez ve mevcut 5 sütun dizinine tek bir sütun eklemek yerine, yeni bir 6 sütun dizini oluşturmanızı önerir.
-- If you have this
CREATE NONCLUSTERED INDEX [IX_MyTable_MyIndex] ON [dbo].[MyTable]
(
[col1] ASC
, [col2] ASC
, [col3] ASC
, [col4] ASC
, [col5] ASC
)
-- But your query would benefit from the addition of a column
CREATE NONCLUSTERED INDEX [IX_MyTable_MyIndex] ON [dbo].[MyTable]
(
[col1] ASC
, [col2] ASC
, [col3] ASC
, [col4] ASC
, [col5] ASC
, [col6] ASC
)
-- SSMS will suggest you create this instead
CREATE NONCLUSTERED INDEX [IX_MyTable_AnotherIndexWithTheSameColumnsAsTheExistingIndexPlusCol6] ON [dbo].[MyTable]
(
[col1] ASC
, [col2] ASC
, [col3] ASC
, [col4] ASC
, [col5] ASC
, [col6] ASC
)Kimberly Tripp , SQL odaklı diğer platformlar için geçerli iken endeksleme stratejisi üzerinde bazı mükemmel malzeme vardır. SQL Server folk için, yukarıdaki örnek gibi kopyaları tanımlamak için bazı kullanışlı araçlar vardır .
Bir sorguyu yürütürken geçici dizin de oluşturabiliriz. Bu tekniklerin artıları ve eksileri nelerdir?
Bu genellikle yalnızca nadiren çalıştırılan sorgular, tipik olarak ETL için geçerlidir. Değerlendirmeniz gerekiyor:
Her iki yaklaşımla da gerçekten riskler var:
Seçenek a) Başlangıçtan itibaren dizin, ancak asla kullanılmayan bir dizi dizin oluşturduğunuzu fark etmeyin. Bunlar bazı ek yükler ekler (en belirgin şekilde verileri değiştiren sorgulara değil, aynı zamanda en iyi dizini belirlemeye çalışan SELECT ifadelerinin optimizasyonu ile).
Artık kullanılmayan dizinleri tanımlamak ve bunları kaldırmak ve denemek için kendinizi disipline etmeniz gerekecektir (PostgreSQL bunu yapabilir; maalesef MySQL, kutudan çıkarken çok zayıf.)
Seçenek b) Kişiler şikayet etmeye başlayana kadar dizin eklemeyin veya tanılama araçlarınız belirli sorguların yavaş olduğunu ve geliştirilebileceğini tetikler.
Sunma riskiniz, dizine ihtiyacınız olduğunu fark ettiğiniz zaman ile eklemeniz gereken zaman arasında yeterince büyük bir zaman aralığınızın olmamasıdır.
PostgreSQL, CONCURRENTLYbu ani endeks-ekleme gereksinimindeki stresin bir kısmını azaltan bina indekslerini destekliyor , ancak kılavuzda not edilen bazı uyarılar var .
Seçenek (b) benim tercihim olma eğilimindedir, ancak her iki seçeneğin bir melezinin muhtemelen en iyi çözüm olduğunu düşünüyorum. Bir endeksin gerçekten kullanılacağını düşünüp düşünmediğinize dair güven seviyenizle ilgilidir.
Bunu özellikle karmaşık bir tartışma yapan şey, dizinleri değiştirmenin genellikle kolay olması, ancak şemayı değiştirmenin daha zor olmasıdır. B'nin gecikmesiz tepkisini umursamaz olmak için bir bahane olarak teşvik etmek istemiyorum .
Mark'ın cevabına ek olarak
Beklenen miktarlarda gerçekçi test verilerine sahip olarak bir fikir edinebilirsiniz. Bir sorgunun 1000 satırla sorunsuz çalıştığı, ancak milyonlarca üretimin olmadığı birçok, çok (çok) durum gördüm.
Yapabiliyorsanız, daha sonra üretimin bir kopyası üzerinde çalışın,
Tabii ki, garip sorunu sadece üretimde gördüm, çünkü her şey aynı olduğunda kullanım kalıpları
Geçici dizinler? ETL yük desenlerinin dışında, bir kez ihtiyacınız varsa tekrar ihtiyacınız olacak. Unutmayın: bir dizin oluşturma / bırakma bir yazmadır ve günlüğe kaydedilir = daha fazla yükleme
Sadece birkaç şey eklemek için.
Bu benim yaklaşımım.
Kullanılmayan sütunlar için nereye > 0veya > ""nereye koyduğunuzdan korkmayın .
select * from blah
where A="one"
and B="two"
and C>="" --to match index
and D="four"
--This will use your existing index. No need to create a redundant one.Sadece ilk soruyu cevaplamaya çalışacağım. Belirli bir süre sonra tablolarınızda kaç kayıt olacağını kabaca en başından tahmin edebiliyorsanız, bazı endeksler tasarlamak için baştan başlamak daha iyi olduğunu söyleyebilirim. En sık kullanılacağını düşündüğünüz uygulama çağrıları için mümkün olduğunca çok çağrıyı otomatikleştirecek bazı test araçlarını veya test komut dosyalarını kullanmaya çalışın ve en başta hangi tablo taramalarının önlenebileceğini göreceksiniz.
Başlangıçta bir tahmin çalışması olacak, ancak zamanla, uygun kullanım istatistiklerine sahip olduğunuzdan, daha net bir görüntünüz olacak.