Bagaimana indeks yang difilter bisa menjadi fitur yang lebih kuat

Jadi pada satu waktu, hanya satu nilai NULL yang bisa ada di kolom ini. Tidak seperti kebanyakan skenario, ini adalah satu kasus di mana SQL Server memperlakukan dua nilai NULL sebagai sama (daripada menentukan bahwa kesetaraan tidak diketahui dan, pada gilirannya, salah). Orang-orang telah mengeluh tentang ketidakkonsistenan ini selama bertahun-tahun.

Jika ini merupakan persyaratan, sekarang kita dapat mengatasinya menggunakan indeks yang difilter:

ALTER TABLE dbo.Personnel DROP CONSTRAINT UQ_SSN;
GO
 
CREATE UNIQUE INDEX UQ_SSN ON dbo.Personnel(SSN)
  WHERE SSN IS NOT NULL;

Sekarang sisipan ke-4 kami berfungsi dengan baik, karena keunikan hanya diterapkan pada nilai non-NULL. Ini adalah jenis kecurangan, tetapi memenuhi persyaratan dasar yang dimaksudkan oleh standar ANSI (walaupun SQL Server tidak mengizinkan kita untuk menggunakan ALTER TABLE ... ADD CONSTRAINT sintaks untuk membuat batasan unik yang difilter).

Tapi, pegang teleponnya

Ini adalah contoh yang bagus tentang apa yang dapat kita lakukan dengan indeks yang difilter, tetapi ada banyak hal yang masih tidak dapat kita lakukan, dan beberapa keterbatasan dan masalah yang muncul sebagai akibatnya.

Pembaruan statistik

Ini adalah salah satu batasan IMHO yang lebih penting. Indeks yang difilter tidak mendapat manfaat dari pembaruan otomatis statistik berdasarkan persentase perubahan subset tabel yang diidentifikasi oleh predikat filter; itu didasarkan (seperti semua indeks yang tidak difilter) pada churn terhadap seluruh tabel. Ini berarti, bergantung pada persentase tabel dalam indeks yang difilter, jumlah baris dalam indeks dapat menjadi empat kali lipat atau separuh dan statistik tidak akan diperbarui kecuali Anda melakukannya secara manual. Kimberly Tripp telah memberikan beberapa informasi hebat tentang ini (dan Gail Shaw mengutip contoh di mana dibutuhkan 257.000 pembaruan sebelum statistik diperbarui untuk indeks yang difilter yang hanya berisi 10.000 baris):

http://www.sqlskills.com/blogs/kimberly/filtered-indexes-and-filtered-stats-might-become-serius-out-of-date/
http://www.sqlskills.com/ blogs/kimberly/category/filtered-indexes/

Selain itu, rekan Kimberly, Joe Sack (@JosephSack), telah mengajukan item Connect yang menyarankan untuk memperbaiki perilaku ini untuk indeks yang difilter dan statistik yang difilter.

Filter batasan ekspresi

Ada beberapa konstruksi yang tidak dapat Anda gunakan dalam predikat filter, seperti NOT IN , OR dan predikat dinamis/non-deterministik seperti WHERE col >= DATEADD(DAY, -1, GETDATE()) . Selain itu, pengoptimal mungkin tidak mengenali indeks yang difilter jika predikatnya tidak sama persis dengan WHERE klausa dalam definisi indeks. Berikut adalah beberapa item Connect yang mencoba membujuk beberapa dukungan untuk cakupan yang lebih baik di sini:

Penggunaan potensial lainnya saat ini tidak memungkinkan

Saat ini kami tidak dapat membuat indeks yang difilter pada kolom terkomputasi yang bertahan, meskipun itu deterministik. Kami tidak dapat mengarahkan kunci asing ke indeks terfilter yang unik; jika kita ingin indeks mendukung kunci asing selain kueri yang didukung oleh indeks yang difilter, kita harus membuat indeks kedua, redundan, non-filter. Dan berikut adalah beberapa batasan serupa lainnya yang telah diabaikan atau belum dipertimbangkan:

Masalah dengan MERGE

Dan MERGE muncul lagi di daftar "hati-hati" saya:

Sementara salah satu bug ini (tampaknya terkait erat) mengatakan bahwa itu diperbaiki di SQL Server 2012, Anda mungkin perlu menghubungi PSS jika Anda menemukan variasi apa pun dari masalah ini, terutama pada versi sebelumnya (atau berhenti menggunakan MERGE , seperti yang telah saya sarankan sebelumnya).

Keterbatasan alat / DMV / bawaan

Ada banyak DMV, perintah DBCC, prosedur sistem, dan alat klien yang mulai kita andalkan seiring waktu. Namun, tidak semua hal ini diperbarui untuk memanfaatkan fitur baru; indeks yang difilter tidak terkecuali. Item Connect berikut menunjukkan beberapa masalah yang mungkin membuat Anda tersandung jika Anda mengharapkannya berfungsi dengan indeks yang difilter:

Untuk tiga yang terakhir, jangan menahan nafas – Microsoft tidak mungkin menginvestasikan waktu dalam prosedur sp_, DMV, tampilan INFORMATION_SCHEMA, dll. Lihat penulisan ulang sp_helpindex Kimberly Tripp, yang mencakup informasi tentang indeks yang difilter di sepanjang dengan fitur baru lainnya yang ditinggalkan Microsoft.

Batasan Pengoptimal

Ada beberapa item Connect yang menjelaskan kasus di mana indeks yang difilter *dapat* digunakan oleh pengoptimal, tetapi diabaikan. Dalam beberapa kasus, ini tidak dianggap "bug" melainkan "celah dalam fungsionalitas"…

Paul White (@SQL_Kiwi) baru-baru ini memposting di sini di SQLPerformance.com sebuah postingan yang menjelaskan secara detail tentang beberapa batasan pengoptimal di atas.

Dan Tim Chapman menulis posting bagus yang menguraikan beberapa batasan lain dari indeks yang difilter – seperti ketidakmampuan untuk mencocokkan predikat dengan variabel lokal (diperbaiki pada 2008 R2 SP1) dan ketidakmampuan untuk menentukan indeks yang difilter dalam petunjuk indeks.

Kesimpulan

Indeks yang difilter memiliki potensi besar dan saya memiliki harapan yang sangat tinggi saat pertama kali diperkenalkan di SQL Server 2008. Namun, sebagian besar batasan yang disertakan dengan versi pertama masih ada hingga saat ini, satu setengah (atau dua, tergantung pada Anda perspektif) rilis utama nanti. Di atas sepertinya daftar cucian yang cukup luas dari barang-barang yang perlu ditangani, tetapi saya tidak bermaksud untuk menemukan cara itu. Saya hanya ingin orang-orang menyadari sejumlah besar potensi masalah yang mungkin perlu mereka pertimbangkan saat memanfaatkan indeks yang difilter.