Pengaruh indeks pada pernyataan pembaruan di mana kolom pembaruan tidak ada dalam indeks

Saya selalu melihat orang mengatakan bahwa indeks melambat update, deletedan insert. Ini digunakan sebagai pernyataan selimut, seolah-olah itu mutlak.

Sementara menyetel basis data saya untuk meningkatkan kinerja, saya terus menghadapi situasi ini yang tampaknya bertentangan dengan aturan itu secara logis untuk saya, dan di mana pun saya tidak dapat menemukan orang mengatakan atau menjelaskan dengan cara apa pun sebaliknya.

Dalam SQL Server, dan saya percaya / menganggap sebagian besar DBMS lainnya, indeks Anda dibuat berdasarkan kolom spesifik yang Anda tentukan. Sisipan dan penghapusan akan selalu memengaruhi seluruh baris, jadi tidak mungkin mereka tidak akan memengaruhi indeks, tetapi pembaruan tampaknya sedikit lebih unik, mereka hanya dapat memengaruhi kolom tertentu saja secara spesifik.

Jika saya memiliki kolom yang tidak termasuk dalam indeks apa pun dan saya memperbaruinya, apakah itu diperlambat hanya karena saya memiliki indeks pada kolom lain dalam tabel itu?

Sebagai contoh, katakan dalam Usertabel saya, saya memiliki satu atau dua indeks, kunci utama yang merupakan kolom Peningkatan Identitas / Otomatis, dan mungkin yang lain pada beberapa kolom kunci asing.
Jika saya memperbarui kolom tanpa indeks langsung di atasnya, seperti misalnya nomor telepon atau alamat mereka, apakah pembaruan ini melambat karena saya memiliki indeks pada tabel ini di kolom lain di kedua situasi? Kolom yang saya perbarui tidak dalam indeks, jadi secara logis, indeks tidak boleh diperbarui, bukan? Jika ada, saya akan berpikir mereka dipercepat jika saya menggunakan indeks di klausa WHERE.

Anda benar bahwa memperbarui kolom yang tidak diindeks tidak akan menyebabkan perubahan pada indeks. Dalam kasus sederhana, juga tidak akan ada dampak keseluruhan pada tabel.

Jika kueri dapat menggunakan Indeks untuk mencari data, itu dapat mempercepat pencarian, tetapi perilaku yang tepat (tergantung pada merek SQL Anda) mungkin berbeda dari merek SQL lain. (Saya menggunakan Microsoft SQL Server terutama.)

Tentu saja, memperbarui kolom dengan volume data yang jauh lebih besar dapat menyebabkan perpindahan baris ke halaman yang berbeda, dan lain-lain.

Untuk sistem modern yang relatif cepat, penambahan satu indeks ke tabel OLTP mungkin hampir tidak terdeteksi dari sudut pandang kinerja untuk sebagian besar sistem . Karena itu, Anda seharusnya tidak membuat indeks yang tidak perlu, dan Anda mungkin tidak boleh membuat indeks satu kolom untuk setiap kolom dalam sebuah tabel.

Anda benar dalam asumsi bahwa untuk banyak pertanyaan keberadaan indeks yang berguna akan menghasilkan peningkatan kecepatan yang sangat nyata.

Meskipun pertanyaan Anda tampaknya seputar kinerja, ada beberapa masalah potensial lainnya seputar penambahan indeks, termasuk tetapi tidak terbatas pada:

1. Waktu yang diperlukan untuk membuat indeks dapat mengakibatkan pemblokiran sementara indeks ditambahkan ke tabel. Kunci ini berumur pendek, dan kemungkinan besar tidak akan membuat masalah besar.

2. Perubahan indeks mengakibatkan rencana eksekusi tidak valid untuk semua rencana yang merujuk tabel yang mendasarinya. Ketika rencana eksekusi tersebut dikompilasi ulang, kinerja dapat berubah negatif untuk beberapa permintaan.

3. Modifikasi indeks dapat menghasilkan kueri yang mengembalikan kesalahan di mana tidak ada yang sebelumnya dikembalikan. Ambil kasus indeks yang difilter yang digunakan untuk mengembalikan tanggal yang terkandung dalam bidang varchar; jika filter menghilangkan baris apa pun yang bukan tanggal, dan filter yang kemudian diubah, kueri yang bergantung pada indeks itu sekarang mungkin gagal ketika mencoba untuk mengkonversi data non-tanggal.

4. Indeks baru dapat menyebabkan urutan eksekusi berubah yang mengakibatkan kemungkinan deadlock terjadi di tempat yang sebelumnya tidak terjadi.

Jika operasi pembaruan menargetkan kolom ukuran tetap yang tidak diindeks (seperti bilangan bulat), biasanya tidak lambat, tetapi dibandingkan dengan pernyataan pilih, pembaruan tersebut akhirnya harus ditulis pada disk lambat juga.