Rencana pelaksanaan vs perintah STATISTIK IO

Paket eksekusi grafis SQL Server membaca dari kanan ke kiri dan atas ke bawah. Apakah ada urutan yang berarti untuk output yang dihasilkan oleh SET STATISTICS IO ON?

Pertanyaan berikut:

SET STATISTICS IO ON;

SELECT  *
FROM    Sales.SalesOrderHeader AS soh
        JOIN Sales.SalesOrderDetail AS sod ON soh.SalesOrderID = sod.SalesOrderID
        JOIN Production.Product AS p ON sod.ProductID = p.ProductID;

Buat rencana ini:

Dan STATISTICS IOoutput ini :

Table 'Worktable'. Scan count 0, logical reads 0, physical reads 0, read-ahead reads 0, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0.
Table 'SalesOrderDetail'. Scan count 1, logical reads 1246, physical reads 3, read-ahead reads 1277, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0.
Table 'SalesOrderHeader'. Scan count 1, logical reads 689, physical reads 1, read-ahead reads 685, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0.
Table 'Product'. Scan count 1, logical reads 15, physical reads 1, read-ahead reads 14, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0.

Jadi, saya tegaskan: apa yang terjadi? Apakah ada pemesanan yang berarti untuk STATISTICS IOoutput atau apakah ada perintah sewenang-wenang yang digunakan?

Awal saya bermain-main dengan berbagai pertanyaan menyarankan tidak ada pola sama sekali tetapi pada memperhatikan lebih dekat tampaknya dapat diprediksi untuk rencana serial. Saya berakhir di KB314648 yang @AustinZellner menyebutkan:

Setiap koneksi SQL Server memiliki struktur status proses terkait (PSS) yang memelihara informasi keadaan koneksi khusus. Setiap ID proses server unik (SPID) dalam tabel sistem sysprocesses mewakili PSS yang berbeda, dan informasi dalam tabel virtual sysprocesses adalah "tampilan" ke dalam informasi status ini.

Dan bagian yang relevan dengan pertanyaan Anda:

Jika STATISTIK IO diaktifkan untuk koneksi, SQL Server mengalokasikan array selama eksekusi permintaan untuk melacak informasi IO pada basis per-tabel. Saat SQL Server memproses kueri, itu mencatat setiap permintaan logis untuk halaman dalam entri tabel yang sesuai dalam array ini, bersama dengan apakah permintaan IO logis menghasilkan IO fisik. SQL Server mengembalikan informasi, di akhir permintaan, dalam pesan kesalahan 3615.

Perilaku yang diamati menunjukkan bahwa entri dibuat ke array dalam urutan IO dihasilkan, pada dasarnya hasil dari GetNext () pada operator fisik. Entri terakhir dalam output statistik adalah tabel pertama yang menghasilkan IO yang direkam, entri pertama adalah tabel terakhir. Saya berspekulasi bahwa pesanan untuk rencana paralel tidak dapat diprediksi (atau kurang begitu) karena tidak ada jaminan untuk tugas paralel mana yang akan dijadwalkan terlebih dahulu.

Menurut saya itu adalah urutan sebaliknya dari akses baca data dalam rencana. Paket pertama Anda akan membaca dari tabel Produk untuk membangun tabel hash (meja kerja). Dari yang dibaca dari SalesOrderHeader dan bentuk SalesOrderDetail menggabungkan mereka dengan operator bergabung gabungan. Meja kerja kemudian dibaca dari yang terakhir untuk hash-cocok dengan baris Produk asli dengan orang-orang dari gabungan bergabung. Itu adalah urutan kebalikan yang tepat di mana mereka tercantum dalam output statistik Anda.

Namun, saya tidak mengetahui adanya dokumentasi yang akan menentukan ini. Jika Anda ingin memastikan apa yang terjadi dengan akses tabel pesanan, baca rencana eksekusi.

Saya selalu berpikir itu memiliki perintah, dari belakang ketika saya melakukan lebih banyak pemrograman daripada administrasi. Saya menjalankan beberapa rencana eksekusi dan mengecek kepercayaan saya.

Inilah yang saya lihat:

Dalam kueri multi-langkah (seperti banyak prosedur tersimpan kami), urutan mencerminkan urutan fisik di mana kueri dijalankan.

Untuk permintaan tertentu, sepertinya statistik IO mencerminkan rencana eksekusi dengan melaporkan statistik mulai dari kanan dan bekerja ke kiri.

Mungkin ini lebih dari sekadar pengamatan.

Jadi saya berpikir bahwa hasil statistik io memberikan lebih banyak wawasan tentang apa yang sebenarnya terjadi pada saat runtime, karena akan memperhitungkan dan dipengaruhi oleh kebutuhan untuk membaca dari disk, bukan cache, dan juga dipengaruhi oleh izin akun. bahwa kueri sedang dijalankan di bawah. Posisi tabel dalam statistik kembali kemudian dipengaruhi oleh faktor-faktor lain selain yang dipertimbangkan oleh profiler.

Berikut ini adalah artikel kb yang memberikan wawasan dan beberapa contoh: http://support.microsoft.com/kb/314648