Tabel berkerumun adalah B-Tree tanpa bagian "tumpukan" - baris disimpan langsung dalam struktur B-Tree dari indeks pengelompokan (kunci utama). Node B-Tree dapat dipecah atau digabungkan, sehingga lokasi fisik atau baris dapat berubah, jadi kami tidak dapat memiliki "penunjuk" sederhana dari indeks sekunder ke baris, sehingga indeks sekunder harus menyertakan salinan lengkap dari bidang indeks utama untuk dapat mengidentifikasi baris dengan andal.
Ini berlaku untuk Oracle, MS SQL Server dan juga berlaku untuk InnoDB .
Yang berarti indeks sekunder dalam tabel berkerumun "lebih gemuk" daripada indeks sekunder dalam tabel berbasis tumpukan, yang:
- menurunkan pengelompokan data,
- menurunkan efektivitas cache,
- membuatnya lebih mahal perawatannya,
- dan yang paling penting, memiliki konsekuensi pada kinerja kueri:
- Meminta melalui indeks sekunder mungkin memerlukan pencarian ganda - satu pencarian melalui indeks sekunder untuk menemukan data "kunci" dan satu melalui yang utama, untuk menemukan baris itu sendiri (Oracle memiliki beberapa pengoptimalan yang menarik untuk menghindari pencarian kedua, tetapi InnoDB tidak, setahu saya).
- Di sisi lain, indeks sekunder secara alami mencakup lebih banyak bidang, sehingga pencarian kedua dapat dihindari sama sekali di mana indeks berbasis tumpukan tradisional akan memerlukan akses tabel. Namun, efek yang sama dapat dicapai dalam indeks berbasis tumpukan, hanya dengan menambahkan lebih banyak bidang ke dalamnya.
Izinkan saya mengutip Gunakan Indeks, Luke! :"Kelebihan tabel indeks-terorganisir dan indeks berkerumun sebagian besar terbatas pada tabel yang tidak memerlukan indeks kedua."
Sayang sekali, karena MySQL tidak mengizinkan Anda memilih pengelompokan secara independen dari mesin penyimpanan.
