Sebuah indeks, berkerumun atau tidak berkerumun, dapat digunakan oleh pengoptimal kueri jika dan hanya jika kunci paling kiri dalam indeks difilter. Jadi jika Anda mendefinisikan indeks pada kolom (A, B, C), kondisi WHERE pada [email protected] , di [email protected] atau di [email protected] AND [email protected] tidak akan sepenuhnya memanfaatkan indeks (lihat catatan). Ini berlaku juga untuk kondisi join. Filter WHERE apa pun yang menyertakan A akan mempertimbangkan indeks:[email protected] atau [email protected] AND [email protected] atau [email protected] AND [email protected] atau [email protected] AND [email protected] AND [email protected] .
Jadi dalam contoh Anda jika Anda membuat indeks berkerumun di part_no sebagai kunci paling kiri, lalu kueri mencari part_id tertentu akan tidak gunakan indeks dan indeks non-cluster yang terpisah harus ada di part-id .
Sekarang tentang pertanyaan mana dari banyak indeks yang harus berkelompok satu. Jika Anda memiliki beberapa pola kueri yang memiliki kepentingan dan frekuensi yang sama dan saling bertentangan dalam hal kunci yang diperlukan (mis. kueri yang sering dilakukan oleh salah satu part_no atau part_id ) maka Anda mempertimbangkan faktor lain:
- lebar :kunci indeks berkerumun digunakan sebagai kunci pencarian oleh semua indeks non-cluster lainnya. Jadi jika Anda memilih kunci lebar (katakanlah dua kolom uniquidentifier) maka Anda membuat semua indeks lainnya lebih lebar, sehingga menghabiskan lebih banyak ruang, menghasilkan lebih banyak IO dan memperlambat semuanya. Jadi di antara kunci yang sama bagusnya dari sudut pandang baca, pilih yang paling sempit sebagai berkerumun dan buat yang lebih lebar tidak berkerumun.
- pertikaian :jika Anda memiliki pola penyisipan dan penghapusan tertentu, coba pisahkan secara fisik sehingga pola tersebut muncul pada bagian berbeda dari indeks berkerumun. Misalnya. jika tabel bertindak sebagai antrian dengan semua sisipan di satu ujung logis dan semua dihapus di ujung logis lainnya, coba tata letak indeks berkerumun sehingga urutan fisik cocok dengan urutan logis ini (mis. urutan enqueue).
- mempartisi :jika tabel sangat besar dan Anda berencana untuk menyebarkan partisi maka kunci partisi harus indeks berkerumun. Contoh umum adalah data historis yang diarsipkan menggunakan skema partisi jendela geser. Meskipun entitas memiliki kunci utama logis seperti 'entity_id', indeks berkerumun dilakukan oleh kolom datetime yang juga digunakan untuk fungsi partisi.
- stabilitas :kunci yang sering berubah adalah kandidat yang buruk untuk kunci yang dikelompokkan karena setiap memperbarui nilai kunci yang dikelompokkan dan memaksa semua indeks non-clustered untuk memperbarui kunci pencarian yang mereka simpan. Karena pembaruan kunci yang dikelompokkan juga kemungkinan akan memindahkan catatan ke halaman lain, hal itu dapat menyebabkan fragmentasi pada indeks yang dikelompokkan.
Catatan:tidak sepenuhnya leverage karena terkadang mesin akan memilih indeks non-cluster untuk scan bukannya indeks berkerumun hanya karena lebih sempit dan dengan demikian memiliki lebih sedikit halaman untuk dipindai. Dalam contoh saya jika Anda memiliki indeks di (A, B, C) dan filter WHERE di [email protected] dan kueri memproyeksikan C , indeks kemungkinan akan digunakan tetapi bukan sebagai pencarian, sebagai pemindaian, karena masih lebih cepat daripada pemindaian berkerumun penuh (halaman lebih sedikit).
