Saya perhatikan bahwa sangat sedikit orang yang memahami cara kerja indeks di SQL Server, terutama Kolom yang Disertakan. Namun demikian, indeks adalah cara terbaik untuk mengoptimalkan kueri. Pada awalnya, saya juga tidak mendapatkan ide tentang kolom yang disertakan, tetapi percobaan saya menunjukkan bahwa kolom tersebut sangat berguna.
Misalkan, kita memiliki tabel dan kueri berikut:
CREATE TABLE Person ( PersonID int, FirstName varchar(100), LastName varchar(100), Age int, … … ) SELECT FirstName, LastName, Age FROM Person WHERE FirstName = 'John' and LastName = 'Smith'
Jelas bahwa PersonID adalah kunci utama. Misalkan kita memiliki indeks dengan nama depan dan belakang, sebut saja IX_Person_FirstNameLastName. Rencana eksekusi untuk kueri semacam itu akan terlihat sebagai berikut:
- Menemukan semua baris dengan nama depan dan belakang yang ditentukan dengan bantuan pohon indeks IX_Person_FirstNameLastName
- Mendeteksi lokasi sebenarnya dari garis pada disk pada indeks akan keluar, menuju ke lokasi sebenarnya dan membaca usia.
Sekarang, mari kita pertimbangkan bahwa kueri ini cukup sering dieksekusi. Kita harus menjalankan 2 langkah setiap kali. Apakah bisa dioptimalkan? Dalam kasus MS SQL Server, ini bukan masalah – Anda dapat memasukkan nilai langsung ke dalam indeks dengan bantuan opsi INCLUDE.
CREATE INDEX IX_PERSON ON Person ( FirstName, LastName ) INCLUDE(Age)
Sekarang, bidang ini tidak digunakan selama pengindeksan tetapi termasuk dalam indeks. Masalah apa yang bisa kita hadapi dalam hal ini? Saat kita mengindeks tabel berdasarkan bidang tertentu, server database harus membuat pohon indeks berdasarkan bidang ini. Ini berarti bahwa kita perlu mengubah pohon indeks saat mengubah nilainya. Ketika nilai dimodifikasi secara intensif, itu menjadi tugas yang bermasalah dan sulit bagi server. Saat memperbarui menjadi terlalu besar, terkadang lebih mudah untuk menjatuhkan indeks. Indeks sangat mengoptimalkan pencarian tetapi berdampak negatif pada operasi penyisipan, penghapusan, dan pembaruan.
Jika suatu bidang hanya disertakan dalam indeks, bidang itu tidak digunakan selama pembuatan pohon indeks dan tidak memengaruhinya, tetapi nilai dapat dengan mudah ditemukan pada daun pohon ini. Ketika pencarian berdasarkan nama belakang dan depan dilakukan, server mencari semua nama depan dan belakang dari pohon, dan ketika mencapai daun (menemukan nilai indeks yang diperlukan), selain penunjuk ke lokasi fisik dari nilai baris, itu juga berisi nilai bidang yang termasuk dalam indeks. Artinya, tidak perlu mengambil langkah kedua untuk beralih ke lokasi fisik baris dan membacanya dari sana.
Karena Anda tidak perlu mengubah struktur pohon saat memodifikasi data usia, semua hal ini tidak banyak memengaruhi operasi modifikasi data. Kita tidak perlu mengubah indeks, kita hanya perlu mengubah nilai pada daun pohon. Itulah mengapa bahkan perubahan besar pada bidang Age tidak akan berdampak besar pada kinerja. Itu pasti akan berpengaruh, tapi tidak terlalu banyak.
Sejauh yang saya tahu, nilai indeks berkerumun secara otomatis termasuk dalam level daun, tetapi ini harus diperiksa dengan spesifikasi.
Jadi, kapan penggunaan bidang yang disertakan bermanfaat? Ketika mereka sering digunakan dalam hasil kueri tetapi diubah sesekali. Contohnya adalah tabel transaksi bank. Tabel tersebut dapat terdiri dari bidang-bidang berikut:nomor rekening, jenis transaksi, tanggal, jumlah. Tidak ada gunanya mengindeks dengan jumlah, tetapi kita dapat memasukkannya ke dalam indeks dan itu akan mempercepat kueri secara signifikan.
Untuk mengambil efek nyata dari pengindeksan, kueri tidak boleh memilih semua bidang, yaitu kita harus melupakan tabel SELECT * FROM. Selalu hitung ulang hanya bidang yang benar-benar Anda butuhkan. Dan jika nilainya masuk dalam indeks, kecepatan eksekusi mungkin cukup tinggi.
Alat yang berguna:
dbForge Index Manager – add-in SSMS yang berguna untuk menganalisis status indeks SQL dan memperbaiki masalah dengan fragmentasi indeks.
