Kullanılmayan Dizinlere İlişkin En İyi Uygulamalar


11

Bu sorguya dayanarak, toplam okumaların düşük bir miktarını (0 veya 0, 1 veya 2 gibi çok yakın) ve yüksek veya orta miktarda kullanıcı güncellemelerini (bu sorgu ile ekler veya silmeyi bulamadım) görürsem büyük bir satır sayısı, teorik olarak dizin kaldırmak gerekir .

SELECT DISTINCT
    OBJECT_NAME(s.[object_id]) AS ObjectName
       , p.rows TableRows
       , i.name AS [INDEX NAME]
       , (user_seeks + user_scans + user_lookups) AS TotalReads
       , user_updates UserUpdates
FROM sys.dm_db_index_usage_stats s
    INNER JOIN sys.indexes i ON i.[object_id] = s.[object_id] 
        AND i.index_id = s.index_id 
    INNER JOIN sys.partitions p ON p.object_id = i.object_id
WHERE OBJECTPROPERTY(s.[object_id],'IsUserTable') = 1
       AND s.database_id = DB_ID()
       AND i.name IS NOT NULL
ORDER BY (user_seeks + user_scans + user_lookups) ASC

Bu varsayımın doğruluğunu burada kontrol etmek istiyorum. Örneğin, bir yıldan uzun bir süredir var olan ancak hiç okunmamış, ancak son derece güncellenmiş bir dizin, sahip olmak kötü bir fikir gibi görünüyor. Bu varsayımın geçersiz olduğu bir senaryo var mı?

Yanıtlar:


15

Bu DMV yalnızca son SQL Server yeniden başlatıldığından beri istatistikleri korur; görünüm tamamen silinir ve her şey sıfırdan başlar.

Daha da önemlisi, belirli bir dizin için bu görünümdeki satırlar, bu dizin yeniden oluşturulduğunda kaldırılır (ancak yeniden düzenlendiğinde kaldırılmaz). Düzenli dizin bakımı gerçekleştiriyorsanız, bakım günlüklerine bakmak ve bırakmayı düşündüğünüz dizinlerden herhangi birinin yakın zamanda yeniden oluşturulmuş olup olmadığını görmek yararlı olabilir.

Bu nedenle, son yeniden başlatmanın geçen haftaki Salı güncellemeleri ya da dünün hizmet paketi için son yeniden başlatmanın yapılmış olabileceği düşük okumalara dayanarak karar vermek akıllıca olmayabilir. Veya son yeniden yapılandırmadan bu yana dizin bakımı gerçekleştirirken. Sadece ayda bir veya çeyrek kez veya yılda bir kez yayınlanan ve önemli ve sabırsız bir kişi tarafından yürütülen bir rapor olabilir.

Ayrıca, gelecekte bilmediğiniz bir şey için bir indeks olabilir - vergi sezonu için bir dizi rapor hazırlanıyor.

Benim tavsiyem:

Kaldırılacak aday dizinleri tanımlamak için DMV'yi kullanın , ancak bu kararı bir balonun içinde yapmayın - bir dizinin , kullanılmıyormuş gibi görünse bile, bir dizinin düşmeden önce neden var olabileceğini belirlemek için ayak işi yapmanız gerekir. .


@AaronBertrand Peki bir geçmişi izlemek (son yeniden başlatma zamanıyla birlikte) buna iyi bir katkı olur mu? Cevabınız için teşekkürler.
DoubleVu

1
@DoubleVu evet, dizin kullanım geçmişinin anlık görüntülerinin korunması muhtemelen faydalıdır, böylece kullanım istatistikleri DMV'nin çıktısını değiştirebilecek herhangi bir şeyden etkilenmeyen eğitimli kararlar verebilirsiniz.
Aaron Bertrand

2

Yup görünümde sadece son yeniden başlatmadan bu yana istatistikler var. Bakım penceremiz, sunucunun yeniden başlatılmasından önce her ay bilgileri yakalamaya başlamadan önce, sabahları aylık yayınladığınız gibi bir sorguyu çalıştıran bir işi ayarladığımı azaltmak için. Bu, daha da geriye gitmeme ve zaman içindeki eğilimlere bakmama izin verdi. Ayrıca muhtemelen eksik dizinleri arıyor koştu ikinci bir sorgu vardı.

Dikkate alınması gereken başka bir şey, tablodaki diğer dizinlerin neler olduğudur. Çoğunlukla veya tamamen başka bir dizinin kopyası olduğu için kullanılmıyor olabilir. Evet. SQL sunucusu iki farklı ama aynı dizin oluşturmanıza izin verir, böylece tamamen yedekli olabilir.

Ayrıca, söz konusu dizin kaldırıldıysa, sorgu planının o dizini kullanan bir sorgu için ne olabileceğini de görebilirsiniz. Kullanılacak başka bir dizine sahip olacak mı yoksa büyük olasılıkla tam tablo taramasına geri dönecek mi?

Endeksler bilim olduğu kadar sanattır, çünkü neyin çalıştırılabileceği hakkında her şeyi bilmek gerçekten zordur ve yine de sık sık değişir.

Sitemizi kullandığınızda şunları okuyup anladığınızı kabul etmiş olursunuz: Çerez Politikası ve Gizlilik Politikası.
Licensed under cc by-sa 3.0 with attribution required.