Birincil Anahtar yerine Kapatma Sütunları ile Benzersiz Kümelenmemiş Dizin kullanmanın sonuçları


12

Büyük bir tablo [MyTable]anda hem bir sahiptir Primary Key, ve bir Unique Non Clustered Indexaynı sütunda ( [KeyColumn]). U NC endeksinde ek kaplama sütunları da vardır.

Aynı sütunlarda hem PK hem de Benzersiz NC Dizini'ne sahip olmak gereksiz görünüyor, bu yüzden Birincil Anahtarı silmeyi ve bunun yerine Referans Bütünlüğü amacıyla Benzersiz Kümelenmemiş dizini kullanmayı düşünüyordum.

Tablonun tamamen başka bir sütunla kümelendiğini unutmayın.

yani Yani:

ALTER TABLE [MyTable]
    ADD CONSTRAINT [PK_MyTable] 
    PRIMARY KEY NONCLUSTERED ([KeyColumn])
GO

VE

CREATE UNIQUE NONCLUSTERED INDEX [IX_MyTable_SomeIndex] 
    ON [MyTable] ([KeyColumn]) 
    INCLUDE ([Column1], [Column2])
GO

Bildiğim kadarıyla, Birincil Anahtar'a kaplama sütunları eklemek mümkün değil, bu yüzden yapmak niyetindeyim:

  • Yabancı Anahtar Kısıtlamalarına bağlı bırak MyTable.KeyColumn
  • Birincil Anahtarı MyTable.KeyColumntamamen bırakın
  • Tabloya yabancı anahtarları yeniden ekleme (RI yoluyla uygulanacaktır yani MyTable.KeyColumn)

Bunu yapmayı düşünebileceğim tek sonuç, ERD diyagramlarımızda görsel anahtar sembolünü alamayacağımız ve dahil edilen sütunlar nedeniyle (yaprak) dizin yoğunluğunun daha az olacağıdır.

Https://stackoverflow.com/questions/487314/primary-key-or-unique-index adresini okudum ve bunu yapmanın bütünlüğü ve performans yönlerinden memnunum.

Sorum şu: Bu yaklaşım kusurlu mu?

Düzenlemeye çalıştığım şeyi düzenle : Performans Optimizasyonu ve Bahar Temizliği . PK veya Dizin kaldırıldığında, dizinlerim için daha az sayfa gerekir = daha hızlı yazma, ayrıca bakım / işletim avantajları, yani birleştirilmiş tutmak için bir daha az dizin vb.

Bunu biraz arka plana koymak için, daha önce hiç bir PK olmadan referans alınan bir tablo yoktu. Ancak, tabloya sütunları içeren bir NC Dizini eklenmiş olması, düşüncelerimi uyarlamam gerektiği anlamına geliyor.


Neyi başarmaya çalıştığınız hakkında yorum yapabilir misiniz? Sonunda kümelenmiş bir dizin bulduğunuzdan emin olmalısınız.

@ jn29098 - Güncellendi. Ne PK ne de kaplama sütunları olan sütunlarda kümelenmiş bir dizinimiz olduğunu doğruladık, bu nedenle bu kararla ilgili görünmüyor.
StuartLC

1
PK'nin gittiğini görünce engelleyecek hiçbir araç / ORM / veri oluşturma modelleme aracınız olmadığından emin misiniz?
Remus Rusanu

Gördüğüm tek dezavantajı, PK gittiğinde ... keycolumn üzerinde sadece bir dizin var ve PK dizinini kullanan sorgular, keycolumn veya keycolumns tarafından sipariş ve Uniuqe endeksi tarafından kapsanmayan endeks taraması için söyleyebilir. benzersiz indeks yaprak sayfaları PK'nınkinden çok daha fazla.Aksi takdirde iyi görünüyor.Ama bazı safkan PK olması gerektiğini söyleyecek :)
Gulli Meel

1
Dizin kullanım istatistiklerini DMV kullanarak bu dizinin kullanışlılığını kontrol etmenizi ve bazı sorgularınız tarafından kullanılıp kullanılmadığını görmenizi öneririz.Ayrıca benzersiz anahtar dizinine karşı kontrol edin ve ardından bunu kullanarak sorguya ne olacağını tanımlayın index ..
Gulli Meel

Yanıtlar:


3

Performans Optimizasyonu. PK veya Dizin kaldırıldığında, dizinlerim için daha az sayfa gerekir = daha hızlı yazma, ayrıca bakım / operasyonel faydalar, yani birleştirilmiş tutmak için bir daha az dizin vb.

Teklif edilenlerin gerçekten yardımcı olacağını kanıtlamanız gerekir (maliyet ve fayda). Bu değişiklik hangi nedenle dikkate alınıyor? Aslında bu tabloyla ilgili performans sorunları var mı, yoksa sadece "yanlış görünüyor" mu?

Ortamınız için en iyi karara ulaşmanıza yardımcı olacak başka sorular:

  • Bakım penceresinde ne kadar zaman kazanılır? Yedekleme penceresinde?

  • Bu ne kadar depolama alanı tasarrufu sağlar (veri dosyaları, günlük dosyaları, yedeklemeler, vb.)?

  • INSERTbu masada performans gerçekten bir darboğaz şu anda? Ne kadar iyileşir? Bir dizini kaldırmak bu sorunu çözmek için en iyi strateji midir?

  • Bu, her bir tablonun yalnızca benzersiz bir dizine değil birincil bir anahtara sahip olmasını bekleyen veritabanı araçları ve çerçeveleri (özellikle ORM'ler) ile ilgili sorunlara neden olur mu? İşlemsel Çoğaltma , yayımlanan tablolarda birincil anahtar gerektirir .

  • Kendi kendini belgeleyen bir veritabanı şeması önemli mi?

  • Sınırlı kullanımına rağmen, birincil anahtar endeksinin darlığı, optimize edicinin belirli sorgular için daha verimli planlar üretmesine izin veriyor mu? (Öğrenmek sys.dm_db_index_usage_statsiçin kullanın .)

Kişisel olarak konuşursak, bize söylediklerinizden, hem (a) ekstra indeksin bir sorun olduğu, hem de (b) kaldırılması çözüm olduğu kanıtlanana kadar onu yalnız bırakırım.


Teşekkürler - endeks istatistiklerinin PK'nın hala taramalar için yoğun olarak kullanıldığını gösterdi. Görünüşe göre aşırı hevesliyim - PK'yi elde tutmanın okunabilirlik / konvansiyonun faydaları uzun vadede herhangi bir depolama etkisinden daha ağır basmalıdır. İşlemsel çoğaltma ile ilgili nokta, bunu destekliyor - bu veritabanını kısa süre içinde çoğaltmamız gerekecek.
StuartLC

2

Bu tabloda daha kötü (ve biraz daha kötü) performans gösteren tek sorgu türü, bir dizi KeyColumn değeri isteyen sorgular olacaktır - şu anda bu sorgular en iyi şekilde PK'nizdeki bir dizin araması tarafından sunulacaktır.

Bu tabloya referans veren tablolar için referans bütünlük kontrolü maliyetinin daha yüksek olacağını (yine sadece biraz daha yüksek) akılda tutmak gerekir.

Sıfırlanabilir yön ile ilgilendiğiniz sürece, tek bir endeksle iyi olmalısınız.

Benim DB olsaydı, muhtemelen tek benzersiz dizin için gitmek istiyorum, diğer tüm şeyler eşit.


Teşekkürler - referans bağlantınız var mı? wrt biraz daha kötü, sadece kaplama endeksindeki düşük endeks yoğunluğuna mı atıfta bulunuyorsunuz, yoksa buna neden olacak başka bir şey var mı?
StuartLC

Ne yazık ki çok fazla deneyimden ve yıllar boyunca benden daha akıllı insanlarla sohbet etmek! Ve evet, tam olarak - sayfa başına daha az satır olacak, bu yüzden daha fazla G / Ç olacak. Ancak - INCLUDE sütunlarının yalnızca yaprak seviyesinde bulunduğunu belirtmek gerekir. Yani hepsi kötü değil. Sorunuzun ayrıntılarına dayanarak bunu bildiğinizden eminim, ancak diğer okuyucuların olmayabilir.
Matt Whitfield

-2

Bildiğim kadarıyla, Birincil Anahtar'a kaplama sütunları eklemek mümkün değil

KeyColumn üzerinde kümelenmiş bir dizininiz varsa, o zaman kümelenmiş bir dizin olduğundan, diğer tüm sütunlar örtük olarak 'kapsanır'. Böylece KeyColumn üzerinde başka bir dizin ekleyerek hiçbir şey elde edemezsiniz. Aslında kesici uçlarınızı yavaşlatacak ve daha fazla alan kullanacaksınız.

Bunun nedeni, kümelenmiş bir dizin bu şekilde bir dizin değil, yalnızca tablonun satırlarını dizin sırasına göre depolamak için bir yönerge olmasıdır. Bir kez birincil anahtarla sıraya koyduğunuzda, o zaman diğer tüm sütunlara sahipsiniz.


2
İlk paragraftan:The table is clustered by another column entirely.
JNK

5
Burada bazı birincil anahtar / kümelenmiş dizin karışıklığı olabilir düşünüyorum. Yönetim stüdyosunun sizi ikna etmek için gösterdiği tüm çabalara rağmen, bunlar aynı şey değildir.
Matt Whitfield
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.