Implikasi menggunakan Indeks NonClustered Unik dengan Meliputi Kolom bukan Kunci Utama

Kami memiliki tabel besar [MyTable]yang saat ini memiliki a Primary Key, dan a Unique Non Clustered Indexpada kolom yang sama ( [KeyColumn]). Indeks U NC juga memiliki kolom penutup tambahan.

Memiliki kedua PK dan Indeks NC Unik pada kolom yang sama tampaknya berlebihan, jadi saya sedang mempertimbangkan menghapus Kunci Utama dan sebagai gantinya menggunakan indeks Unik Non Clustered untuk keperluan Integritas Referensial.

Perhatikan bahwa tabel dikelompokkan oleh kolom lain seluruhnya.

Yaitu Jadi kita memiliki:

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

DAN

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

Sejauh yang saya tahu, tidak mungkin menambahkan kolom penutup ke Kunci Utama, jadi saya bermaksud untuk melakukan:

Jatuhkan Batasan Kunci Asing bergantung pada MyTable.KeyColumn
Jatuhkan Kunci Utama MyTable.KeyColumnsepenuhnya
Tambahkan kembali kunci asing ke tabel (yaitu RI akan diberlakukan melalui MyTable.KeyColumn)

Satu-satunya implikasi yang dapat saya pikirkan untuk melakukan ini adalah bahwa kita tidak akan mendapatkan simbol kunci visual pada diagram ERD kita, dan bahwa kepadatan indeks (daun) akan lebih sedikit karena kolom yang disertakan.

Saya telah membaca /programming/487314/primary-key-or-unique-index dan saya senang dengan aspek integritas dan kinerja dalam melakukan ini.

Pertanyaan saya adalah: Apakah pendekatan ini cacat?

Edit Apa yang saya coba capai : Optimasi Kinerja dan Pembersihan Musim Semi . Dengan menghapus baik PK atau Indeks, akan ada lebih sedikit halaman yang dibutuhkan untuk indeks saya = menulis lebih cepat, ditambah juga manfaat pemeliharaan / operasional, yaitu satu indeks lebih sedikit untuk terus defrag dll.

Untuk menjelaskan hal ini, saya belum pernah punya meja yang direferensikan, tanpa PK. Namun, fakta bahwa Indeks NC dengan kolom penutup ditambahkan ke tabel berarti bahwa saya perlu menyesuaikan pemikiran saya.

sql-server sql-server-2008

— StuartLC
sumber

Bisakah Anda mengomentari apa yang ingin Anda capai? Anda juga harus memastikan bahwa Anda berakhir dengan indeks berkerumun pada akhirnya.

@ jn29098 - Diperbarui. Dikonfirmasi bahwa kami memiliki indeks berkerumun, pada kolom yang bukan merupakan PK maupun kolom penutup, jadi ini sepertinya tidak relevan dengan keputusan ini.

— StuartLC

Anda yakin tidak memiliki alat / ORM / alat pemodelan data generasi yang akan muntah ketika melihat PK hilang?

— Remus Rusanu

Satu-satunya kekurangan yang saya lihat adalah bahwa setelah PK hilang .. maka Anda hanya memiliki satu indeks pada kolom kunci dan permintaan yang menggunakan indeks PK mengatakan untuk pemindaian indeks pada kolom kunci atau memesan dengan kolom kunci dan tidak tercakup oleh indeks Uniuqe mungkin jam IO agak lebih tinggi. karena halaman daun indeks yang unik jauh lebih banyak daripada PK. Jika tidak, itu terlihat baik-baik saja. Tetapi beberapa purist akan mengatakan Anda harus memiliki PK :)

— Gulli Meel

Saya akan menyarankan Anda memeriksa kegunaan indeks itu menggunakan statistik penggunaan indeks DMV dan melihat apakah itu digunakan oleh beberapa pertanyaan Anda. Periksa dengan indeks kunci yang unik juga dan kemudian deicde apa yang akan terjadi pada permintaan menggunakan itu index ..

— Gulli Meel

Jawaban:

Optimalisasi Kinerja. Dengan menghapus baik PK atau Indeks, akan ada lebih sedikit halaman yang dibutuhkan untuk indeks saya = menulis lebih cepat, ditambah juga manfaat pemeliharaan / operasional, yaitu satu indeks lebih sedikit untuk terus defrag dll.

Anda harus dapat membuktikan bahwa apa yang diusulkan akan benar-benar membantu (biaya vs. manfaat). Untuk alasan apa perubahan ini dipertimbangkan? Apakah sebenarnya ada masalah kinerja dengan tabel ini, atau hanya "terlihat salah"?

Berikut beberapa pertanyaan lain yang akan membantu Anda mengambil keputusan terbaik untuk lingkungan Anda:

Berapa banyak waktu yang akan dihemat di jendela perawatan? Di jendela cadangan?
Berapa banyak ruang penyimpanan yang akan dihemat ini (file data, file log, cadangan, dll.)?
Apakah INSERTkinerja pada tabel ini benar - benar menjadi hambatan saat ini? Berapa banyak yang akan ditingkatkan? Apakah menghapus indeks merupakan strategi terbaik untuk memperbaiki masalah itu?
Apakah ini akan menyebabkan masalah dengan alat dan kerangka kerja basis data (khususnya ORM) yang mengharapkan setiap tabel memiliki kunci utama dan bukan hanya indeks unik? Replikasi Transaksional membutuhkan kunci utama pada tabel yang diterbitkan.
Apakah skema basis data yang mendokumentasikan sendiri penting?
Meskipun penggunaannya terbatas, apakah sempitnya indeks kunci utama masih memungkinkan pengoptimal untuk menghasilkan rencana yang lebih efisien untuk permintaan tertentu? (Gunakan sys.dm_db_index_usage_statsuntuk mencari tahu.)

Secara pribadi, dari apa yang telah Anda katakan kepada kami, saya akan membiarkannya sampai dapat dibuktikan bahwa kedua (a) indeks tambahan adalah masalah, dan (b) menghapusnya adalah solusinya.

— Jon Seigel
sumber

Terima kasih - ternyata statistik indeks menunjukkan bahwa PK masih banyak digunakan untuk pemindaian. Tampaknya saya terlalu bersemangat - manfaat keterbacaan / konvensi mempertahankan PK harus lebih besar daripada implikasi penyimpanan dalam jangka panjang. Intinya tentang replikasi transaksional berhasil - kami akan segera mereplikasi database ini.

— StuartLC

Satu-satunya jenis kueri pada tabel itu yang akan berkinerja lebih buruk (dan hanya sedikit lebih buruk) adalah mereka yang meminta berbagai nilai KeyColumn - karena pertanyaan tersebut saat ini akan lebih baik dilayani oleh pencarian indeks di PK Anda.

Perlu diingat bahwa biaya pemeriksaan integritas referensial untuk tabel yang mereferensikan tabel ini akan lebih tinggi (sekali lagi hanya sedikit lebih tinggi).

Selama Anda mengurus aspek yang dapat dibatalkan, maka Anda harus baik-baik saja dengan satu indeks.

Jika itu DB saya, saya mungkin akan memilih satu indeks unik, semua hal lain dianggap sama.

— Matt Whitfield
sumber

Terima kasih - apakah Anda memiliki tautan referensi? wrt sedikit lebih buruk, apakah Anda mengacu hanya pada kepadatan indeks yang lebih rendah dalam indeks penutup, atau ada hal lain yang akan menyebabkan ini?

— StuartLC

Sayangnya itu hanya dari banyak pengalaman, dan mengobrol dengan orang-orang yang jauh lebih pintar daripada saya selama bertahun-tahun! Dan ya, justru itu - akan ada lebih sedikit baris per halaman, jadi lebih banyak I / O. Namun - perlu dicatat bahwa kolom INCLUDE hanya ada di level daun. Jadi tidak semuanya buruk. Saya yakin Anda tahu itu berdasarkan detail dalam pertanyaan Anda, tetapi saya kira pembaca lain mungkin tidak.

— Matt Whitfield

-2

Sejauh yang saya tahu, tidak mungkin untuk menambahkan kolom penutup ke Kunci Utama

Jika Anda memiliki indeks berkerumun di KeyColumn, maka karena itu adalah indeks berkerumun, semua kolom lainnya secara implisit 'tertutup'. Jadi Anda tidak mendapatkan apa-apa dengan menambahkan indeks lain di KeyColumn. Bahkan Anda akan memperlambat sisipan Anda dan menggunakan lebih banyak ruang.

Ini karena indeks berkerumun bukan indeks seperti itu, tetapi hanya instruksi untuk menyimpan baris tabel dalam urutan indeks. Dan setelah Anda menemukan satu baris dengan kunci utama, maka Anda memiliki semua kolom lainnya di sana.

— David Roussel
sumber

Dari paragraf pertama:The table is clustered by another column entirely.

— JNK

Saya pikir mungkin ada beberapa kunci primer / kebingungan indeks yang terjadi di sini. Meskipun upaya terbaik studio manajemen untuk membujuk Anda, mereka bukan hal yang sama.

— Matt Whitfield