Indeks database digunakan untuk mempercepat operasi tabel yang berbeda. Namun sebelum Anda membuat indeks, penting untuk mengetahui apakah Anda benar-benar membutuhkan indeks? Dan jika Anda perlu membuat indeks, apa saja poin penting yang harus diperhatikan? Di sinilah desain indeks database masuk.
Artikel ini bertujuan untuk menjawab pertanyaan-pertanyaan tentang desain indeks database dan menyoroti beberapa pertimbangan utama yang harus dipertimbangkan oleh pengembang database ketika merancang sebuah Indeks.
1. Ukuran Tabel
Pertanyaan pertama yang harus ditanyakan oleh pengembang database sebelum membuat indeks adalah apakah tabel cukup besar untuk menggunakan indeks secara efisien atau tidak. Jika ukuran tabel kecil, mesin SQL Server dapat memindai tabel lengkap lebih cepat daripada mencari tabel melalui indeks. Indeks dalam kasus seperti itu tidak ada gunanya dan membuat overhead saat melakukan operasi database.
2. Jenis Kolom
Indeks harus dibuat pada kolom kunci utama atau kolom apa pun yang berisi nilai unik dan yang memiliki batasan NOT NULL. Selanjutnya, disarankan untuk membuat indeks pada kolom numerik karena kolom numerik cenderung memiliki nilai yang lebih unik dibandingkan dengan kolom non-numerik. Desain indeks database yang buruk menggunakan indeks pada kolom yang memiliki entri unik yang sangat sedikit dan dapat menghasilkan kueri yang sangat memakan waktu.
Pertimbangkan tabel bernama Pasien yang berisi ratusan ribu catatan. Tabel Pasien akan berisi kolom yang disebut "Jenis Kelamin" yang hanya dapat memiliki dua nilai unik "Pria" dan "Wanita". Jika Anda membuat indeks pada "Kolom Jenis Kelamin", catatan akan diurutkan dalam urutan abjad menaik atau menurun.
Jadi jika Anda memiliki satu juta catatan di tabel Pasien dan jumlah pasien pria dan wanita sama, dalam indeks setengah juta catatan pertama akan memiliki jenis kelamin "Perempuan" dan setengah juta kedua akan memiliki jenis kelamin "Laki-laki". Sekarang jika Anda ingin mencari perempuan yang ada di 490.000 baris catatan perempuan, SQL Server Engine harus memindai melalui 490.000 catatan. Di sisi lain, dengan nilai numerik unik, pencarian bisa sangat cepat karena indeks SQL Server disimpan dalam bentuk B + Trees, sehingga nilai numerik di node pohon dapat mempercepat operasi database.
3. Jumlah Indeks
Secara resmi Anda dapat membuat satu indeks berkerumun dan sebanyak mungkin indeks yang tidak berkerumun untuk setiap tabel database. Namun, itu adalah desain indeks database yang baik untuk membuat satu indeks berkerumun dan hanya sejumlah indeks non-cluster yang benar-benar diperlukan. Membuat terlalu banyak indeks yang tidak berkerumun sebenarnya dapat memperlambat operasi Perbarui dan Sisipkan karena ketika catatan diperbarui atau dimasukkan dan nilai kolom diubah, semua indeks terkait harus diperbarui.
Pertimbangkan skenario di mana kami memiliki dua indeks non-cluster, indeks pertama mengurutkan catatan berdasarkan usia dan indeks kedua mengurutkan catatan berdasarkan jenis kelamin dan usia.
Ini adalah indeks pertama:
Usia | Rekam Alamat |
10 | Catat alamat |
22 | Catat alamat |
29 | Catat alamat |
32 | Catat alamat |
33 | Catat alamat |
36 | Catat alamat |
40 | Catat alamat |
49 | Catat alamat |
54 | Catat alamat |
59 | Catat alamat |
Dan ini yang kedua:
Jenis Kelamin | Usia | Rekam Alamat |
Wanita | 10 | Catat alamat |
Wanita | 29 | Catat alamat |
Wanita | 33 | Catat alamat |
Wanita | 40 | Catat alamat |
Wanita | 54 | Catat alamat |
Pria | 22 | Catat alamat |
Pria | 32 | Catat alamat |
Pria | 36 | Catat alamat |
Pria | 49 | Catat alamat |
Pria | 59 | Catat alamat |
Sekarang jika catatan dengan usia 40 harus diperbarui ke usia 15 untuk beberapa alasan, maka indeks pertama harus diperbarui untuk memindahkan catatan dari posisi 7 (40) ke posisi kedua untuk menjaga indeks diurutkan. Demikian pula pada indeks kedua, rekor di indeks ke-4 akan dipindahkan ke indeks kedua. Banyak perombakan yang harus dilakukan. Oleh karena itu adalah bijaksana untuk menjaga jumlah indeks seminimal mungkin untuk kolom yang diperbarui secara berkala ketika memikirkan desain indeks basis data. Juga satu kolom tidak boleh digunakan di beberapa indeks yang tidak berkerumun.
4. Lokasi Penyimpanan Indeks
Lokasi penyimpanan indeks dapat mempengaruhi kinerja kueri yang menggunakan indeks dan juga merupakan bagian dari desain indeks basis data yang baik. Secara default indeks berkerumun disimpan dalam filegroup yang sama dengan tabel di mana indeks dibuat. Untuk indeks yang tidak berkerumun, indeks dapat disimpan dalam grup file yang sama atau dalam grup file berbeda yang mencakup beberapa drive disk. Kinerja kueri indeks non-cluster dapat ditingkatkan secara signifikan dengan menyimpan indeks non-clustered pada beberapa drive disk. Ini karena kinerja input/output kueri akan ditingkatkan sebagai hasil dari data yang didistribusikan di berbagai area drive.
Lokasi penyimpanan default indeks juga dapat diubah dengan menentukan nilai untuk opsi FILLFACTOR. Karena, indeks disimpan secara fisik dalam bentuk Pohon B+, data indeks disimpan di halaman daun. Dengan opsi FILLFACTOR, Anda dapat mengatur persentase halaman tingkat daun yang akan diisi. Misalnya, jika Anda menetapkan nilai FILLFACTOR ke 70%, hanya 70% dari total ruang halaman tingkat daun yang akan diisi oleh data indeks. 30% sisanya akan dibiarkan untuk pertumbuhan otomatis data indeks di masa mendatang.
5. Jenis Indeks
Pertimbangan lain yang sangat penting dalam desain indeks database adalah jenis indeks yang akan digunakan. Pada artikel sebelumnya (tambahkan tautan ke artikel “Kapan Menggunakan Indeks Clustered atau Non-Clustered”) saya menjelaskan perbedaan antara indeks clustered dan non-clustered. Saya juga menjelaskan apa itu dan bagaimana mereka dapat digunakan. Keputusan apakah akan memilih indeks berkerumun atau tidak berkerumun sangat penting dan harus dipikirkan matang-matang.
Poin-poin berikut harus diingat saat memutuskan jenis indeks mana yang akan dipilih.
- Untuk kolom yang digunakan dalam kueri SELECT/JOIN/GROUP BY/BETWEEN, gunakan indeks berkerumun.
- Gunakan indeks non-cluster untuk kolom di mana Anda hanya ingin mengambil nilai dari kolom tertentu dan bukan dari kolom lain di baris yang sama. Kueri SELECT yang mengambil beberapa catatan menggunakan indeks non-cluster bisa lambat karena mesin SQL Server pertama-tama mencari nilai kolom di mana indeks dibuat dan kemudian menggunakan referensi baris untuk nilai kolom, catatan dari tabel database sebenarnya diambil .
- Untuk kolom yang sering menjalani operasi INSERT dan UPDATE, gunakan indeks non-cluster. Pastikan untuk tidak menggunakan satu kolom di beberapa indeks yang tidak berkerumun karena hal itu dapat memperlambat kueri pembaruan. Indeks berkerumun bisa lambat untuk operasi INSERT/UPDATE karena baris lengkap harus diperbarui, bukan hanya nilai kolom tunggal seperti halnya dengan indeks non-cluster.
- Karena Anda hanya dapat membuat satu indeks berkerumun, jika Anda memerlukan beberapa indeks, gunakan indeks yang tidak berkerumun. Namun, jika ruang disk menjadi perhatian utama, pertahankan jumlah indeks yang tidak berkerumun seminimal mungkin.
Pertimbangan Lain
Meskipun ini adalah lima bagian terpenting dari desain indeks basis data, mereka bukanlah segalanya. Penting untuk menentukan urutan kolom yang benar dalam indeks. Sebagai aturan praktis, kolom yang digunakan untuk pengambilan keputusan dalam klausa WHERE, dan kondisi seperti lebih besar dari (>), kurang dari (<), dll, harus ditempatkan sebelum kolom yang tidak terlibat dalam klausa ini. Dalam kasus beberapa kolom dalam klausa WHERE, nama kolom yang paling berbeda harus disebutkan paling awal dalam definisi Indeks.
Selain desain indeks database, desain kueri juga memainkan peran penting dalam efisiensi penggunaan desain indeks. Untuk pemeliharaan indeks yang dioptimalkan daripada menulis beberapa kueri yang beroperasi pada sejumlah kecil baris, cobalah untuk menulis lebih sedikit kueri yang memengaruhi jumlah baris tabel yang lebih besar.
Kesimpulan
Artikel ini menjelaskan beberapa pertimbangan utama yang harus dipertimbangkan oleh pengembang basis data saat melihat desain indeks basis data. Artikel tersebut juga menjelaskan alasan di balik pertimbangan ini dan berisi saran lebih lanjut untuk memastikan bahwa desain indeks database Anda efisien.