Apakah buruk memiliki ruang indeks lebih besar dari ruang data?

Seringkali saya perlu menjalankan kueri terhadap tabel besar yang tidak memiliki indeks yang tepat. Jadi saya meminta DBA untuk membuat indeks tersebut. Hal pertama yang dia lakukan adalah melihat statistik tabel dan melihat ukuran ruang indeks.

Seringkali dia akan memberitahu saya untuk mencari solusi alternatif karena "indeksnya sudah lebih besar dari tabel". Dia merasa indeks harus lebih kecil dari data, karena, dia mengatakan kepada saya "apakah Anda pernah melihat indeks dalam sebuah buku? Ini jauh lebih kecil daripada buku itu sendiri, dan begitulah seharusnya indeks tabel".

Saya tidak merasa filosofinya benar, tetapi saya tidak bisa menantangnya karena dia adalah DBA utama dan saya seorang pengembang. Saya merasa jika permintaan membutuhkan indeks, indeks hanya harus dibuat, alih-alih menemukan "solusi" yang hanya membuat SP yang tidak dapat dibaca dan tidak dapat dipelihara.

Saya hanya memilih kolom yang diperlukan. Masalahnya adalah saya memfilter berdasarkan tanggal sehingga mesin perlu melakukan pemindaian tabel agar sesuai dengan kolom. Kueri berjalan sekali sehari, pada malam hari, untuk mengumpulkan statistik, tetapi butuh 15 menit untuk menjalankan (kami memiliki aturan keras dan cepat lainnya: Tidak ada prosedur yang harus memakan waktu lebih dari 3 menit).

DBA menunjukkan statistik indeks kepada saya. Ada sekitar 10 indeks pada tabel itu, yang hanya 6 digunakan (statistik menunjukkan nol hit ke 4 dari mereka). Ini adalah sistem besar dengan lebih dari 20 pengembang yang berpartisipasi. Indeks dibuat untuk alasan apa pun, dan mungkin tidak lagi digunakan.

Kami diharuskan untuk mendukung SQL Server 2008, karena itulah pengujian DB berjalan. Tetapi klien semuanya pada 2014 dan 2016.

Pikirkan desain indeks seperti saklar geser. Anda dapat memindahkan kenop segitiga merah ini di mana saja di sepanjang garis yang Anda inginkan:

Saya biasanya tidak mengukur dalam hal ukuran - saya biasanya memikirkannya dalam hal jumlah indeks, tetapi ukuran akan baik-baik saja.

Sepertinya DBA Anda menganggap peralihan terlalu jauh ke kanan - bahwa Anda telah menambahkan terlalu banyak indeks, dan penghapusan / pembaruan / sisipan berkinerja terlalu lambat.

Daripada berdebat tentang di mana saklar itu, coba tanyakan kepadanya tentang masalah kinerja yang Anda alami karena tingginya indeks. Mungkin pengguna Anda mengeluh tentang kecepatan hapus / perbarui / masukkan, atau dia melihat kunci menunggu, atau dia kesulitan membuat cadangan basis data karena ukurannya.

Titik awal saya biasanya 5 dan 5: sekitar 5 indeks per tabel, dengan sekitar 5 bidang atau kurang per indeks. Tidak ada yang ajaib tentang angka itu - itu hanya berasal dari kenyataan bahwa saya memiliki 5 jari di masing-masing tangan, jadi mudah untuk mengangkat tangan dan menjelaskan aturannya.

Anda mungkin perlu memiliki banyak indeks KURANG dari 5 ketika beban kerja Anda sangat bias terhadap operasi delete / update / insert, dan Anda tidak memiliki cukup tenaga kuda perangkat keras untuk mengikutinya.

Anda mungkin dapat memiliki banyak indeks LEBIH BANYAK ketika beban kerja Anda sebagian besar hanya-baca, atau ketika Anda banyak berinvestasi dalam perangkat keras (seperti cache seluruh database dalam memori, dan memiliki semua penyimpanan solid state di bawahnya.)

Juga keinginan untuk memiliki lebih dari "The Ozar 5" indeks di atas meja mungkin menunjukkan bahwa Anda memiliki banyak jenis pertanyaan baca-berat di atas meja.

Yang mungkin menunjukkan bahwa Anda bisa mendapatkan keuntungan dari indeks kolomstore berkerumun atau tidak berkerumun di tabel.

Alih-alih memiliki indeks optimtimal untuk masing-masing N jalur akses yang berbeda, toko kolom memberi Anda pemindaian super cepat dan kemampuan untuk melewati kolom yang tidak dibutuhkan, dan segmen baris. Jadi, Anda dapat memiliki sejumlah kecil indeks BTree untuk transaksi super-kritis, dan kembali ke toko kolom untuk yang lainnya.

Indeks Columnstore dirancang untuk bekerja di beban kerja OLTP-berat dengan SQL Server 2016+. Lihat dokumentasi untuk analitik operasional waktu-nyata .

Saya suka jawaban Brents dan saya memutarnya. Saya ingin menambahkan perspektif lain. Saya telah bekerja sebagai pengguna, pengembang dan DBA dan merasa bahwa pendapat tidak relevan. Saya percaya ini tergantung pada pengguna (atau pemangku kepentingan) untuk memutuskan bagaimana suatu kueri berkinerja dan berapa lama untuk mendapatkan hasil. Kemudian tergantung pada pengembang dan DBA untuk bekerja bersama untuk mewujudkannya.

Jika posisi DBA di perusahaan Anda 'bertanggung jawab' atas topik ini, mereka dapat menganalisis permintaan Anda dan memberikan saran tentang desain permintaan yang lebih baik atau menjawab kinerja tersebut.

Jika kueri dan / atau struktur data tidak dapat dimodifikasi untuk mencapai tujuan maka saya pikir turun ke tiga pilihan.

1. Pengambilan data yang lambat
2. Pembaruan data yang lambat
3. Sumber daya perangkat keras lainnya $$$$

Tentu saja setiap situasi memiliki banyak variabel tergantung pada beberapa faktor bisnis dan teknologi, tetapi saya percaya ketiga opsi ini berlaku untuk sebagian besar atau semua kasus.

Tampaknya terlalu ketat untuk melarang tabel indeks>. Jika meja Anda jarang berubah (atau berubah pada malam hari ketika tidak ada banyak kompetisi untuk sumber daya) dan banyak ditanyakan dengan berbagai cara, banyak indeks besar dapat dibenarkan. DBA juga harus berhati-hati untuk tidak menempel hidung mereka di tempat yang tidak seharusnya. Jika dia memberi Anda / sistem Anda batasan pada gigabyte, ia seharusnya tidak terlalu peduli bagaimana ruang itu digunakan. Jika dia terlalu banyak bekerja, ini mungkin sebabnya.

Namun ada banyak hal yang perlu dipertimbangkan:

• Banyak indeks membuat sisipan / pembaruan / penghapusan lebih lambat. Jadi, jika meja Anda banyak berubah, berhati-hatilah untuk tidak membuatnya terlalu banyak.
• Ruang juga bisa menjadi masalah. Bukan hanya karena gigabytes membutuhkan biaya (tidak banyak saat ini), tetapi juga waktu karena cadangan akan lebih lambat (tergantung pada bagaimana cadangan dilakukan).
• Sebagian besar database serius dapat dimonitor untuk menemukan indeks yang jarang atau tidak pernah digunakan. Pertimbangkan untuk menjatuhkan beberapa di antaranya.
• Terkadang Anda berpikir Anda perlu indeks, tetapi ketika Anda memeriksa kueri Anda lebih dekat, itu dapat disetel dan ditulis ulang secara berbeda dengan hasil yang sama dan tanpa perlu indeks. Gunakan jelaskan rencana untuk melihat apakah indeks digunakan atau tidak.
• Kadang-kadang kolom terakhir dapat dijatuhkan dari indeks multi-kolom tanpa banyak hit kinerja. Dan kadang-kadang ini bahkan dapat membuat pertanyaan lebih cepat karena ruang penyimpanan indeks lebih kecil dan lebih banyak indeks akan disimpan / di-cache dalam memori pada waktu tertentu.
• Indeks berbasis fungsi dapat menggantikan yang normal untuk menghemat lebih banyak ruang. Contoh: alih-alih menanyakan nama lengkap, permintaan untuk dua huruf pertama juga ( where substr(surname, 1, 2) = substr(<userinput>, 1, 2) and surname=<userinput>) dan create index i on customers(substr(surname,1,2)). Ini mungkin cukup cepat dan indeks Anda akan lebih kecil.
• Database mendukung berbagai jenis indeks. Beberapa jenis menggunakan ruang lebih sedikit daripada yang lain. Mungkin beberapa indeks Anda dapat dikonversi ke jenis yang lebih hemat ruang? Pastikan untuk terlebih dahulu memahami jenis indeks yang berbeda dan untuk situasi apa mereka baik dan buruk.
• Jika pekerjaan batch yang jarang adalah satu-satunya hal yang membutuhkan indeks spesifik, pertimbangkan untuk membuat indeks itu hanya untuk pekerjaan batch itu dan drop setelahnya.