Properti baru "Actual Rows Read" dalam rencana eksekusi (yang di SQL Server Management Studio ditampilkan sebagai "Number of Rows Read") adalah tambahan yang disambut baik untuk tuner kinerja. Ini seperti memiliki kekuatan super baru, untuk dapat memberi tahu pentingnya Predikat Seek v Predikat Residual dalam operator Seek. Saya suka ini, karena ini bisa sangat penting untuk kueri.
Mari kita lihat dua kueri, yang saya jalankan terhadap AdventureWorks2012. Mereka sangat sederhana – yang satu mencantumkan orang-orang bernama John S, dan yang lainnya mencantumkan orang-orang yang disebut J Smith. Seperti semua buku telepon yang bagus, kami memiliki indeks di LastName, FirstName.
select FirstName, LastName from Person.Person where LastName like 'S%' and FirstName = 'John'; select FirstName, LastName from Person.Person where LastName = 'Smith' and FirstName like 'J%';
Jika Anda penasaran, saya mendapatkan 2 baris kembali dari yang pertama, dan 14 baris kembali dari yang kedua. Saya sebenarnya tidak terlalu tertarik dengan hasilnya, saya tertarik dengan rencana pelaksanaannya.
Mari kita lihat apa yang terjadi. Saya membuka salinan SQL Sentry Plan Explorer yang lebih lama, dan membuka paket saya secara berdampingan. Kebetulan - Saya telah menjalankan kedua kueri bersama dan kedua paket berada di file .sqlplan yang sama. Tapi saya bisa membuka file yang sama dua kali dalam PE, dan dengan senang hati meletakkannya berdampingan di grup tab.
Besar. Mereka terlihat sama! Saya dapat melihat bahwa Seek di sebelah kiri menghasilkan dua baris, bukan empat belas – jelas ini adalah kueri yang lebih baik.
Tetapi dengan jendela yang lebih besar, saya akan melihat lebih banyak informasi, dan beruntung saya telah menjalankan dua kueri dalam kumpulan yang sama.
Anda dapat melihat bahwa kueri kedua, yang menghasilkan 14 baris, bukan 2 baris, diperkirakan menghabiskan lebih dari 80% biaya! Jika saya menjalankan kueri secara terpisah, masing-masing akan menunjukkan kepada saya 100%.
Sekarang mari kita bandingkan dengan rilis terbaru dari Plan Explorer.
Hal yang langsung muncul di benak saya adalah peringatannya. Mari kita lihat sedikit lebih dekat.
Peringatan mengatakan “Operasi menyebabkan sisa IO. Jumlah sebenarnya dari baris yang dibaca adalah 2.130, tetapi jumlah baris yang dikembalikan adalah 2. Benar saja, lebih jauh kita melihat "Actual Rows Read" mengatakan 2.130, dan Actual Rows di 2.
Wah! Untuk menemukan baris itu, kami harus melihat melalui 2.130?
Soalnya, cara Seek berjalan adalah dengan mulai memikirkan tentang Predikat Seek. Itulah yang memanfaatkan indeks dengan baik, dan yang sebenarnya menyebabkan operasi menjadi Seek. Tanpa Predikat Seek, operasi menjadi Scan. Sekarang, jika Predikat Seek ini dijamin paling banyak satu baris (seperti ketika memiliki operator kesetaraan pada indeks unik), maka kita memiliki pencarian Singleton. Jika tidak, kami memiliki Pemindaian Rentang, dan rentang ini dapat memiliki Awalan, Awal, dan Akhir (tetapi tidak harus Awal dan Akhir). Ini mendefinisikan baris dalam tabel yang kami minati untuk Seek.
Tapi 'tertarik' tidak selalu berarti 'kembali', karena kita mungkin memiliki lebih banyak pekerjaan yang harus dilakukan. Pekerjaan itu dijelaskan dalam Predikat lain, yang sering dikenal sebagai Predikat Residual.
Sekarang Predikat Residual mungkin benar-benar melakukan sebagian besar pekerjaan. Itu pasti ada di sini – memfilter semuanya dari 2.130 baris menjadi hanya 2.
Pemindaian Rentang dimulai dalam indeks di "John S". Kita tahu bahwa jika ada "John S", ini pasti baris pertama yang bisa memuaskan semuanya. "Ian S" tidak bisa. Jadi kita bisa mencari ke dalam indeks pada saat itu untuk memulai Pemindaian Jangkauan kita. Jika kita melihat pada XML Plan kita dapat melihat ini secara eksplisit.
Perhatikan bahwa kami tidak memiliki Prefix. Itu berlaku ketika Anda memiliki kesetaraan di kolom pertama dalam indeks. Kami hanya memiliki StartRange dan EndRange. Awal rentang adalah "Lebih Besar dari atau Sama" (GE) ScanType, pada nilai "S, John" (referensi kolom di luar layar adalah Nama Belakang, Nama Depan), dan Akhir rentang adalah "Kurang Dari" ( LT) nilai T. Saat pemindaian mencapai T, selesai. Tidak ada lagi yang harus dilakukan. Seek sekarang telah menyelesaikan Range Scan-nya. Dan dalam hal ini, ia mengembalikan 2.130 baris!
Kecuali bahwa itu tidak benar-benar mengembalikan 2.130 baris, itu hanya membaca 2.130 baris. Nama-nama seperti Barry Sai dan Ken Sánchez dibaca, tetapi hanya nama-nama yang memenuhi pemeriksaan berikutnya yang dikembalikan – Predikat Residual yang memastikan bahwa Nama Depan adalah John.
Entri Baca Baris Aktual di properti operator Pencarian Indeks menunjukkan kepada kita nilai 2.130 ini. Dan meskipun terlihat di rilis Plan Explorer sebelumnya, kami tidak mendapat peringatan tentangnya. Itu relatif baru.
Permintaan kedua kami (mencari J Smith) jauh lebih baik, dan ada alasan mengapa itu diperkirakan lebih dari 4 kali lebih murah.
Di sini kita tahu LastName dengan tepat (Smith), dan Range Scan ada di FirstName (J%).
Di sinilah Prefiks masuk.
Kami melihat bahwa Awalan kami adalah operator Kesetaraan (=, ScanType="EQ"), dan Nama Belakang harus Smith. Kami bahkan belum mempertimbangkan Awal atau Akhir rentang, tetapi Awalan memberi tahu kami bahwa rentang tersebut termasuk dalam bagian indeks di mana LastName adalah Smith. Sekarang kita dapat menemukan baris>=J dan
Masih ada Predikat Residual di sini, tetapi ini hanya memastikan bahwa "LIKE J%" benar-benar diuji. Meskipun tampaknya intuitif bagi kami bahwa "LIKE J%" sama persis dengan ">=J dan
Sebelum Service Pack 3 dari SQL Server 2012, kami tidak memiliki properti ini, dan untuk merasakan perbedaan antara Pembacaan Baris Aktual dan Baris Aktual, kami perlu menggunakan bendera jejak 9130. Berikut adalah dua paket tersebut dengan TF itu dihidupkan:
Anda dapat melihat tidak ada peringatan kali ini, karena operator Seek mengembalikan semua 2130 baris. Saya pikir jika Anda menggunakan versi SQL Server yang mendukung Baca Baris Aktual ini, Anda harus berhenti menggunakan tanda pelacakan 9130 dalam penyelidikan Anda, dan mulai melihat peringatan di Plan Explorer. Tetapi yang terpenting, pahami bagaimana operator Anda melakukan pekerjaan mereka, karena dengan begitu Anda akan dapat menafsirkan apakah Anda senang dengan rencana tersebut, atau apakah Anda perlu mengambil tindakan.
Di pos lain, saya akan menunjukkan kepada Anda situasi ketika Anda mungkin lebih suka melihat Baris Aktual Dibaca lebih tinggi daripada Baris Aktual.
@rob_farley
