Database
 sql >> Teknologi Basis Data >  >> RDS >> Database

Apa yang Dapat Diceritakan oleh Rencana Kueri?

Pengantar

Kueri SQL menjelaskan hasil yang diharapkan, bukan cara untuk mendapatkan hasilnya. Serangkaian langkah spesifik yang harus diambil server untuk mengembalikan hasilnya disebut rencana eksekusi kueri. Rencana tersebut dibuat oleh pengoptimal. Pemilihan rencana memengaruhi kecepatan eksekusi, yang menjadikannya salah satu elemen terpenting dari analisis masalah kinerja kueri.

Rencana eksekusi terdiri dari operator dan propertinya yang saling terkait dalam bentuk struktur pohon. Setiap operator bertanggung jawab untuk operasi logis atau fisik yang terpisah. Secara keseluruhan, mereka memastikan hasil yang dijelaskan dalam teks kueri. Di dalam pohon, operator diwakili oleh objek kelas dalam memori SQL Server. Pengguna server (yaitu, Anda dan saya) melihat deskripsi yang dihasilkan dalam format XML dengan skema tertentu, yang ditampilkan secara grafis oleh lingkungan SQL Server Management Studio (SSMS).

Ada banyak berbagai operator paket dan bahkan lebih banyak properti. Selain itu, yang baru muncul dari waktu ke waktu. Artikel ini tidak berani menjelaskan semua kemungkinan variasi operator. Sebagai gantinya, saya ingin membagikan tambahan paling menarik dalam subjek ini dan untuk mengingatkan beberapa elemen lama tapi berguna.

Versi Server

Terkadang Anda dapat menemukan permintaan untuk versi server di forum, meskipun rencana kueri disediakan dalam format yang benar (XML). Sebagai gantinya, Anda dapat menghemat waktu dan membuka rencana eksekusi sebagai XML. Dan elemen pertama yang menjelaskan rencana akan menunjukkan versi server di properti Build.

Metode ini tidak memungkinkan pengambilan informasi lengkap tentang edisi server, tetapi dalam banyak kasus, cukup untuk memahami apa yang kami tangani.

Jumlah Baris Tabel

Pertanyaan umum kedua adalah "Berapa banyak baris yang berisi tabel Anda?". Informasi ini juga dapat diambil dari rencana kueri (seperti dari versi server 2008). Untuk ini, kita perlu memilih operator akses data (Scan atau Seek) dari tabel yang bersangkutan dan lihat TableCardinality Properti. Ada satu lagi properti yang menarik, Estimasi Ukuran Baris, untuk spesifikasi ukuran baris dan evaluasi perkiraan tabel atau ukuran indeks (mengingat bahwa tabel tidak dikompresi).

Saya ingin mencatat bahwa ini bukan jumlah baris yang sebenarnya dalam sebuah tabel, tetapi data dari statistik objek. Namun, data ini adalah dasar untuk keputusan yang dibuat oleh pengoptimal saat membuat kueri.

Konteks

Paket kueri menyimpan pengaturan SET yang penting untuk tujuan pembuatannya. Untuk melihat pengaturan, Anda perlu memilih elemen akar dalam rencana dan memperluas Opsi Atur Properti. Misalnya, kita dapat mempelajari apakah rencana tersebut dibuat dengan ARITHABORT opsi diaktifkan (perbedaan pengaturan ini sering menyebabkan dua rencana dan situasi yang berbeda dengan sniffing parameter yang buruk).

Jumlah CPU

Kami dapat mengambil jumlah prosesor yang tersedia untuk pengoptimal. Untuk ini, kita perlu membuka OptimizerHardwareDependentProperie s -> EstimatedAvailableDegreeOfParallelism parameter dalam elemen root yang sama dan kalikan dengan 2. Jika hanya satu prosesor yang tersedia, tidak perlu mengalikan.

2*2 =4, 4 CPU tersedia. Memang, saya memiliki prosesor 4 inti di komputer saya, dan semua 4 inti tersedia untuk server. Informasi ini dapat membantu Anda mendeteksi mesin tempat rencana dibuat.

Versi Penaksir Kardinalitas

Sejak SQL Server 2014, beberapa versi Cardinality Estimator (RU) telah tersedia. Mekanisme ini memengaruhi sebagian besar keputusan yang diambil pengoptimal saat memilih rencana. Anda dapat mengambil versi Cardinality Estimator dari CardinalityEstimationModelVersion properti dari operator root.

  • 0 – SQL Server <=2012
  • 120 – SQL Server 2014
  • 130 – SQL Server 2016
  • 140 – SQL Server vNext

Waktu Eksekusi Kueri dan Waktu Tunggu

Mulai dari SQL Server 2016 SP1, paket kueri aktual menampilkan informasi tentang waktu eksekusi dan waktu prosesor. Untuk mengambil data ini, Anda perlu memperluas QueryTimeStats properti di elemen root dan lihat nilai CpuTime dan Waktu Berlalu . Kami tidak perlu mengaktifkan kumpulan waktu eksekusi atau bertanya "berapa lama kueri dieksekusi?" lagi – semua informasi ini termasuk dalam rencana.

Peningkatan penting kedua adalah 10 besar dari waktu tunggu terlama selama eksekusi kueri. Untuk ini, kita perlu memperluas WaitStats properti di elemen root. Penambahan ini memungkinkan mendapatkan alasan yang lebih tepat dari eksekusi kueri yang lambat dan menyederhanakan diagnostik secara signifikan.

Jenis Parameter

Daftar Parameter properti, yang mencantumkan parameter yang digunakan dalam kueri, sudah ada dalam rencana sejak lama. Namun, mulai dari SQL Server 2016 SP1, Tipe Data Parameter properti telah ditambahkan ke definisi parameter. Properti ini menyimpan tipe data parameter. Ini dapat berguna untuk memahami masalah dengan konversi jenis.

Jumlah Baris yang Dibaca dan Perkiraan Jumlah Baris yang Akan Dibaca

Rencana eksekusi mencakup dua properti yang sangat penting, Jumlah Baris Aktual dan Perkiraan Jumlah Baris. Properti ini berisi informasi tentang jumlah baris yang dikembalikan oleh operator pembacaan data, tetapi bukan jumlah baris yang sebenarnya telah dibaca. Properti Jumlah Baris yang Dibaca dan Perkiraan Jumlah Baris yang akan Dibaca menjawab pertanyaan ini dan memungkinkan pengambilan jumlah baris yang sebenarnya telah atau akan dibaca oleh server. Properti ActualRowsRead (Jumlah baris yang dibaca di SSMS) tersedia mulai dari SQL Server 2012 SP3, 2014 SP2, 2016 SP1. EstimatedRowsRead Properti (Perkiraan Jumlah Baris untuk Dibaca di SSMS) tersedia mulai dari SQL Server 2016 SP1.

Statistik IO dan Waktu Eksekusi Operator

Ada beberapa properti yang sangat berguna yang dibuat di SQL Server 2016, 2014 SP2 dan tersedia dalam paket kueri yang sebenarnya. Mereka adalah metrik IO (jika operator memiliki IO) – Statistik IO Aktual, metrik CPU dan waktu eksekusi – Statistik Waktu Aktual, dan metrik memori (mulai 2016 SP1, jika operator memerlukan memori).

Properti mencakup metrik baru berikut yang dapat dibagi menjadi utas jika paket paralel:

  • ActualElapsedms
  • CPUm Sebenarnya
  • Pemindaian Aktual
  • ActualLogicalReads
  • Bacaan Fisik yang Sebenarnya
  • AktualReadAheads
  • ActualLobLogicalReads
  • ActualLobPhysicalReads
  • ActualLobReadAheads
  • InputMemoryGrant
  • OutputMemoryGrant
  • UsedMemoryGrant

Seperti yang dapat Anda lihat dari daftar di atas, Anda dapat mengambil informasi lengkap tentang eksekusi setiap operator tertentu, IO yang dikonsumsi, dan memori. Dalam versi SSMS terakhir, metrik ini ditampilkan di jendela properti. Jika Anda menggunakan SSMS versi lama, Anda dapat mengambilnya dengan membuka paket sebagai XML. Menurut pendapat saya, sekarang ada segalanya untuk menunjukkan persentase bukan berdasarkan perkiraan biaya, tetapi dengan sumber daya aktual yang telah berlalu (saya membuat saran di Connect. Jadi, jika Anda menyukai idenya, silakan pilih).

Informasi tentang Tanda Pelacakan yang Diaktifkan

Bendera jejak di SQL Server adalah 'saklar' khusus dari perilaku server default ke beberapa perilaku yang berbeda. Mulai dari SQL Server 2014 SP2 dan 2016 SP1, informasi tentang bendera pelacakan yang diaktifkan tersedia di properti TraceFlags elemen tertentu. Ini dapat mencakup hingga 100 flag yang diaktifkan secara bersamaan pada saat pembuatan kueri.

Informasi tentang Data Tumpahan ke tempdb

Beberapa operator paket, misalnya, seperti Sort atau Hash Match, memerlukan memori selama eksekusi kueri. Namun, volume memori dihitung pada saat kompilasi. Karena berbagai alasan (misalnya evaluasi yang salah dari jumlah atau baris yang seharusnya), volume memori dapat dihitung secara tidak benar. Jika lebih sedikit memori yang dialokasikan daripada yang dibutuhkan untuk eksekusi, server harus menumpahkan data ke tempdb. Ini memperlambat eksekusi kueri. Perhatian tentang situasi seperti itu diperkenalkan di server 2012, tetapi mulai dari SQL Server 2012 SP3, 2014 SP2, 2016, informasi diagnostik telah diperluas, dan sekarang mencakup volume data yang tumpah dan data yang dibaca. Jadi, Anda dapat mengevaluasi masalahnya dan mengambil tindakan yang tepat.

Kesimpulan

Rencana eksekusi mencakup banyak informasi berguna, rencana kueri aktual mencakup lebih banyak informasi, dan rencana kueri aktual di versi terakhir SQL Server hanyalah tambang informasi yang berguna. Artikel ini tidak dimaksudkan untuk mengajari seseorang menganalisis rencana kueri. Sebaliknya, saya mempertimbangkan properti paket yang paling menarik, termasuk properti baru dan properti lama, tetapi diremehkan. Saya harap artikel ini akan membantu Anda di lain waktu ketika Anda perlu menganalisis kinerja kueri.

Artikel diterjemahkan oleh tim Codingsight dengan izin penulis.

Alat yang berguna:

dbForge Query Builder untuk SQL Server – memungkinkan pengguna membuat kueri SQL yang kompleks dengan cepat dan mudah melalui antarmuka visual yang intuitif tanpa penulisan kode manual.


  1. Database
  2.   
  3. Mysql
  4.   
  5. Oracle
  6.   
  7. Sqlserver
  8.   
  9. PostgreSQL
  10.   
  11. Access
  12.   
  13. SQLite
  14.   
  15. MariaDB
  1. Mitos Kinerja :Indeks Clustered vs. Non-Clustered

  2. Cara Membuat Tabel Database dengan SQL

  3. Masalah Performa:Pertemuan Pertama

  4. Menyelidiki Kesalahan ORA 02063 DG4ODBC

  5. SQL GROUP BY- 3 Tips Mudah untuk Mengelompokkan Hasil Seperti Pro