Itu selalu dianjurkan saat menulis kueri atau kode database SQL Server (prosedur dan tampilan) untuk memperhatikan rencana eksekusi. Ada beberapa alasan untuk ini. Pertama – pengoptimal mungkin memilih paket yang tidak Anda harapkan. Misalnya, indeks memindai tabel besar sebelum mencocokkan dengan tabel yang lebih kecil. Kedua – pertimbangan harus diambil untuk bagaimana kueri ini akan tampil dalam beberapa bulan atau tahun mendatang jika kueri berjalan di sistem baru dengan tabel kecil yang akan tumbuh. Dan yang terakhir tetapi yang paling penting, seberapa cepat kueri ini dan berapa banyak sumber daya yang digunakannya. Poin terakhir mungkin tidak terlalu penting, Anda mungkin berpikir selama kurang dari 3 detik itu sudah cukup, tetapi jika bisa berjalan dalam <1 detik, bukankah itu lebih baik? Jika database Anda dihosting di cloud, mengurangi sumber daya juga dapat menghemat uang Anda.
Banyak kasus untuk pengoptimalan SQL biasanya berasal dari masalah yang terdeteksi oleh pengguna akhir atau perangkat lunak pemantauan Anda. “Mengapa laporan ini membutuhkan waktu 30 menit untuk dibuat?”, “Apa yang menyebabkan lonjakan dalam tunggu I/O itu” atau “Mengapa pekerjaan ini membutuhkan waktu dua kali lebih lama untuk dijalankan daripada tahun lalu?”
Dalam semua skenario ini, masih ada beberapa pengetahuan tentang rencana eksekusi dan cara terbaik untuk memperbaiki SQL untuk memperbaiki situasi dan ini bisa sangat memakan waktu dan tidak selalu berhasil.
Mari kita ambil contoh. Jadi, Anda menulis kueri baru, menjalankannya, dan kemudian berpikir, oh sayang, ini terlalu lama.
17 detik untuk 730 baris, apa yang harus saya lakukan?
Pertama, mari kita tinjau rencana eksekusi:
Ini tidak selalu lurus ke depan jika Anda harus memperbesar dan memperkecil untuk memahaminya. Jadi, saran pertama adalah mendapatkan penampil paket yang bagus seperti ini dengan Paket Penyetelan Spotlight.
Penampil paket menyoroti informasi penting yang kami butuhkan dan lokasi operasi utama serta menyoroti peringatan apa pun.
Ini contohnya:
Jadi, ada masalah dengan kode ini, tapi apa yang bisa kita lakukan?
Yah, sebenarnya cukup banyak. Kita bisa menggunakan petunjuk kueri, lihat menambahkan beberapa indeks (jangan lupa ini mungkin memengaruhi kueri dan DML lain), menambahkan bit kode yang tidak mengubah kumpulan hasil tetapi memengaruhi pengoptimal untuk menghasilkan rencana yang berbeda dan sedikit trik untuk hentikan pengoptimal dengan mempertimbangkan indeks tertentu yang digunakannya dan mungkin buat rencana baru. Tapi ini semua trial and error dan sangat memakan waktu untuk dilakukan secara manual.
Dengan menambahkan aplikasi Spotlight Extensions ke SSMS dan berlangganan Spotlight Tuning Pack, kami dapat membiarkan fitur pengoptimalan di Tuning Pack melakukan semua kerja keras untuk kami.
Anda mungkin telah memperhatikan pada tangkapan layar pertama bahwa ketika fitur diaktifkan, fitur tersebut secara otomatis mendeteksi bahwa pengoptimalan dapat dilakukan:
Klik Lihat Analisis
Anda kemudian dapat mengklik tombol Optimalkan dan mesin pengoptimal akan menganalisis kode dan mulai menerapkan aturan penulisan ulang yang akan mengubah sintaks dari SQL memberikan alternatif yang memberikan set hasil yang sama, dan kemudian mengujinya sehingga kami dapat melihat apakah ada eksekusi alternatif rencana lebih cepat dan mengapa. Aturan diterapkan dalam kombinasi sehingga kemungkinan alternatif bisa lebih dari 100. Namun, alat ini hanya menampilkan alternatif yang lebih cepat dari aslinya.
Proses ini berjalan di latar belakang dan menghemat banyak waktu jika Anda mencoba melakukannya secara manual.
Dan ketika hasilnya ditampilkan, Anda dapat membandingkan alternatif, melihat perbedaan kode, membandingkan rencana, dan meninjau statistik.
Jadi, kembali ke SSMS dengan kueri versi baru saya dan ujilah.
Sukses.
Jika ini dalam lingkungan pengembangan, Anda mungkin ingin mempertimbangkan untuk membersihkan cache buffer menggunakan DBCC DROPCLEANBUFFERS, untuk menguji kueri Anda dengan cache buffer dingin tanpa mematikan dan memulai ulang server.
Juga, pertimbangkan untuk menambahkan SET STATISTICS IO ON ke kueri untuk info selengkapnya tentang mengapa sintaks kueri membuat perbedaan:
Asli:
Tulis ulang:
Dan ini juga dapat dicapai dalam Paket Tuning dengan fitur perbandingan statistik:
Jadi, dengan perubahan yang berhasil dan pengguna akhir yang bahagia, lanjutkan ke kueri berikutnya. Dengan terus meningkatkan kinerja kueri individual, kami meningkatkan kinerja instance.
