Penyesuaian Performa Permintaan


12

Saat Anda selesai menulis kueri / proc / fungsi tersimpan, apa cara paling informatif untuk mendapatkan beberapa parameter kinerja dengan cepat? Apakah Anda menjalankan kueri dan melihat rencana eksekusi yang sebenarnya? Jika demikian, apa saja yang Anda cari? Jelas scan tabel / indeks adalah bit hit, tapi apa lagi?

Jawaban:


8

Untuk penilaian cepat, dapatkan rencana eksekusi dari SSMS dan masuk ke Plan Explorer .

  • Tinjau operasi yang paling mahal untuk hal-hal yang tidak terduga. Mengurutkan, meja kerja, bergabung dengan operator yang tidak tepat (misalnya loop bersarang di mana Anda mengharapkan penggabungan atau hash).
  • Lihatlah jumlah baris pada setiap tahap rencana, apakah mereka secara luas dalam kisaran yang Anda harapkan?
  • Lihatlah estimasi baris vs aktual. Jika hasil aktual Anda mendekati perkiraan, kemungkinan Anda memiliki rencana yang bagus. Jika ada variasi besar, cari tahu alasannya (misalnya, statistik yang hilang dan / atau ketinggalan zaman).
  • Mengevaluasi potensi masalah sniffing parameter. Cari area di mana kardinalitas dapat bervariasi dan uji terhadap berbagai parameter input.

Banyak bahan referensi yang tersedia secara bebas di luar sana, Rencana Eksekusi SQL Server Grant Fitchley adalah awal yang baik. Saya juga menemukan posting blog dan ebook Joe Chang tentang rencana biaya yang sangat berguna.


5

Sebagian besar, yang saya lakukan hanyalah menjalankan kueri dan mencari tahu bagaimana mengeksekusi terhadap data dunia nyata. Jika ada masalah, maka saya lihat rencana eksekusi.

Adapun rencana eksekusi, Brad McGehee memiliki artikel yang menarik tentang masalah ini.

Di dalamnya ia berkata:

Jika Anda melihat salah satu dari berikut ini dalam rencana eksekusi, Anda harus mempertimbangkannya sebagai tanda peringatan dan menyelidiki mereka untuk masalah kinerja potensial. Masing-masing dari mereka kurang ideal dari perspektif kinerja.

* Index or table scans: May indicate a need for better or additional indexes.

* Bookmark Lookups: Consider changing the current clustered index, consider using a covering index, limit the number of columns in the SELECT statement.

* Filter: Remove any functions in the WHERE clause, dont include wiews[sic] in your Transact-SQL code, may need additional indexes.

* Sort: Does the data really need to be sorted? Can an index be used to avoid sorting? Can sorting be done at the client more efficiently? 

Tidak selalu mungkin untuk menghindari ini, tetapi semakin Anda dapat menghindarinya, semakin tinggi kinerja kueri.


0
SET STATISTICS IO ON

Secara umum, "jumlah pembacaan logis" harus serendah mungkin. Beberapa halaman menyentuh untuk menyelesaikan kueri, semakin baik rencananya karena (biasanya) akan lebih cepat, dampak yang lebih rendah pada CPU, RAM dan disk IO.

Ini akan memandu Anda ketika mengubah indeks atau re-factoring dari SQL sebenarnya membantu. Melihat "waktu eksekusi milidetik" akan bervariasi bahkan dengan SQL dan rencana kueri yang sama - bacaan logis akan tetap konsisten untuk setiap rencana kueri yang diberikan.

Juga "pembacaan fisik" harus sangat rendah (dan menjadi nol dan tetap nol untuk eksekusi berikutnya). Jika ini tidak melakukan ini maka lihat penggunaan memori SQL Server Anda (halaman hidup dll).


Namun untuk kueri yang dijalankan saat tidak ada dalam cache kueri, bacaan fisik akan lebih besar dari nol, kan? Maksud saya, Anda tidak bisa selalu menyiasatinya, karena tidak semua kueri (terutama kueri ad hoc) di-cache. Apakah saya benar?
Thomas Stringer

@ Surfer513 untuk menangani caching data, Anda dapat mengeluarkan CHECKPOINT diikuti oleh DBCC DROPCLEANBUFFERS untuk menghapus kumpulan buffer (cache data). Perhatikan bahwa ini akan menghapus buffer untuk semua orang, jadi gunakan sesuai (pada sistem uji).
StanleyJohns

@StanleyJohns, mengapa Anda ingin menghapus data / cache cache?
Thomas Stringer

Dengan cara ini IO fisik akan sama setiap kali, memberikan konsistensi yang diperlukan untuk pengujian. Ini akan membantu dalam menyempurnakan permintaan.
StanleyJohns

Saya akan mengabaikan statistik IO fisik karena berada di bawah kendali infrastruktur yang mendasarinya dan akan memasukkan buffering SAN dan OS. IO logis adalah ukuran dari jumlah KERJA yang harus dilakukan oleh pernyataan SQL. Jika SQL kurang IO logis maka itu kurang bekerja.
Guy
Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.