GUID bermasalah sebagai kunci berkerumun karena keacakan yang tinggi. Masalah ini telah diatasi oleh Paul Randal di kolom Tanya Jawab Majalah Technet terakhir:Saya ingin menggunakan GUID sebagai kunci indeks berkerumun, tetapi yang lain berpendapat bahwa itu dapat menyebabkan masalah kinerja dengan indeks. Apakah ini benar dan, jika demikian, dapatkah Anda menjelaskan alasannya?
Sekarang ingatlah bahwa diskusi ini secara khusus tentang berkelompok indeks. Anda mengatakan ingin menggunakan kolom sebagai 'ID', yang tidak jelas apakah yang Anda maksud sebagai kunci berkerumun atau hanya kunci utama. Biasanya keduanya tumpang tindih, jadi saya akan menganggap Anda ingin menggunakannya sebagai indeks berkerumun. Alasan mengapa itu adalah pilihan yang buruk dijelaskan dalam tautan ke artikel yang saya sebutkan di atas.
Untuk indeks yang tidak berkerumun, GUID masih memiliki beberapa masalah, tetapi tidak sebesar ketika mereka adalah kunci tergugus paling kiri dari tabel. Sekali lagi, keacakan GUID memperkenalkan pemisahan dan fragmentasi halaman, baik itu pada tingkat indeks non-clustered saja (masalah yang jauh lebih kecil).
Ada banyak legenda urban seputar penggunaan GUID yang mengutuk mereka berdasarkan ukurannya (16 byte) dibandingkan dengan int (4 byte) dan menjanjikan malapetaka kinerja yang mengerikan jika digunakan. Ini sedikit berlebihan. Sebuah kunci berukuran 16 masih bisa menjadi kunci yang berkinerja sangat baik, pada model data yang dirancang dengan baik. Memang benar bahwa menjadi 4 kali lebih besar dari int menghasilkan lebih banyak halaman non-daun dengan kepadatan lebih rendah dalam indeks, ini bukan masalah nyata untuk sebagian besar tabel. Struktur b-tree adalah pohon yang seimbang secara alami dan kedalaman traversal pohon jarang menjadi masalah, jadi mencari nilai berdasarkan kunci GUID sebagai lawan dari kunci INT serupa dalam kinerjanya. Traversal halaman daun (yaitu pemindaian tabel) tidak melihat halaman non-daun, dan dampak ukuran GUID pada ukuran halaman biasanya cukup kecil, karena catatan itu sendiri secara signifikan lebih besar daripada 12 byte tambahan yang diperkenalkan oleh GUID. Jadi saya akan mengambil saran dengar-dengar berdasarkan 'adalah 16 byte vs. 4' dengan butiran garam yang agak besar. Analisis kasus per kasus dan putuskan apakah dampak ukuran membuat perbedaan nyata:berapa banyak lainnya kolom ada di tabel (mis. seberapa besar pengaruh ukuran GUID pada halaman daun) dan berapa banyak referensi yang menggunakannya (mis. berapa banyak lainnya tabel akan bertambah karena fakta bahwa mereka perlu menyimpan kunci asing yang lebih besar).
Saya menyebut semua detail ini dalam semacam pertahanan darurat GUID karena mereka mendapatkan banyak pers yang buruk akhir-akhir ini dan beberapa tidak layak. Mereka memiliki kelebihan dan sangat diperlukan dalam sistem terdistribusi apa pun (saat Anda berbicara tentang pergerakan data, baik itu melalui replikasi atau kerangka sinkronisasi atau apa pun). Saya telah melihat keputusan buruk dibuat berdasarkan reputasi buruk GUID ketika mereka dijauhi tanpa pertimbangan yang tepat. Tapi benar, jika Anda harus menggunakan GUID sebagai kunci berkerumun, pastikan Anda mengatasi masalah keacakan:gunakan panduan berurutan bila memungkinkan.
Dan terakhir, untuk menjawab pertanyaan Anda:jika Anda tidak memiliki spesifik alasan untuk menggunakan GUID, gunakan INT.
