"Peringatan: Operasi menyebabkan I / O residu" versus pencarian kunci

Saya telah melihat peringatan ini dalam paket eksekusi SQL Server 2017:

Peringatan: Operasi menyebabkan sisa IO [sic]. Jumlah aktual baris yang dibaca adalah (3.321.318), tetapi jumlah baris yang dikembalikan adalah 40.

Berikut ini cuplikan dari SQLSentry PlanExplorer:

Untuk meningkatkan kode, saya telah menambahkan indeks non-cluster, sehingga SQL Server bisa sampai ke baris yang relevan. Ini berfungsi dengan baik, tetapi biasanya akan ada terlalu banyak kolom (besar) untuk dimasukkan dalam indeks. Ini terlihat seperti ini:

Jika saya hanya menambahkan indeks, tanpa menyertakan kolom, akan terlihat seperti ini, jika saya memaksakan penggunaan indeks:

Jelas, SQL Server menganggap pencarian kunci jauh lebih mahal daripada sisa I / O. Saya memiliki pengaturan pengujian tanpa banyak data pengujian (belum), tetapi ketika kode masuk ke produksi, perlu bekerja dengan lebih banyak data, jadi saya cukup yakin bahwa semacam indeks NonClustered diperlukan.

Apakah pencarian kunci benar-benar mahal , ketika Anda menjalankan pada SSD, bahwa saya harus membuat indeks penuh lemak (dengan banyak kolom termasuk)?

Rencana eksekusi: https://www.brentozar.com/pastetheplan/?id=SJtiRte2X Ini adalah bagian dari prosedur lama yang tersimpan. Carilah IX_BatchNo_DeviceNo_CreatedUTC.

Model biaya yang digunakan oleh pengoptimal persis seperti itu: model . Ini menghasilkan hasil yang umumnya baik pada berbagai beban kerja, pada berbagai desain database, pada berbagai perangkat keras.

Anda umumnya tidak boleh berasumsi bahwa perkiraan biaya individu akan sangat berkorelasi dengan kinerja runtime pada konfigurasi perangkat keras tertentu. Inti dari penetapan biaya adalah untuk memungkinkan pengoptimal untuk membuat pilihan berpendidikan antara kandidat alternatif fisik untuk operasi logis yang sama.

Ketika Anda benar-benar masuk ke dalam perincian, seorang profesional basis data yang terampil (dengan waktu luang untuk menyetel kueri penting) seringkali dapat melakukan yang lebih baik. Sejauh itu, Anda dapat menganggap pemilihan paket pengoptimal sebagai titik awal yang baik. Dalam kebanyakan kasus, titik awal itu juga akan menjadi titik akhir, karena solusi yang ditemukan cukup baik .

Dalam pengalaman saya (dan pendapat) biaya pengoptimal permintaan SQL Server pencarian lebih tinggi daripada yang saya inginkan. Ini sebagian besar adalah mabuk dari hari-hari ketika I / O fisik acak jauh lebih mahal dibandingkan dengan akses berurutan daripada yang sering terjadi saat ini.

Tetap saja, pencarian bisa menjadi mahal bahkan pada SSD, atau pada akhirnya bahkan ketika membaca secara eksklusif dari memori. Melintasi struktur b-tree tidak gratis. Jelas biaya meningkat saat Anda melakukan lebih banyak.

Kolom yang disertakan sangat bagus untuk beban kerja OLTP yang berat, di mana pertukaran antara penggunaan ruang indeks dan biaya pembaruan versus kinerja saat membaca runtime masuk akal. Ada juga trade-off untuk dipertimbangkan seputar stabilitas rencana . Indeks yang mencakup sepenuhnya menghindari pertanyaan tentang kapan tepatnya model biaya pengoptimal dapat beralih dari satu alternatif ke yang lain.

Hanya Anda yang dapat memutuskan apakah kompromi tersebut layak untuk kasus Anda. Uji kedua alternatif pada sampel data yang representatif, dan buat pilihan yang tepat.

Dalam komentar pertanyaan yang Anda tambahkan:

Apakah Anda memberi tahu saya bahwa SQL Server tidak mengetahui biaya IO residual?

Tidak, pengoptimal mempertimbangkan biaya sisa I / O. Memang, sejauh menyangkut pengoptimal, predikat non-SARGable dievaluasi dalam Filter terpisah. Filter ini didorong ke pencarian atau pemindaian sebagai residu selama penulisan ulang pasca optimasi .