Sangat mudah untuk mulai mengotak-atik roda gigi pengoptimalan kueri SQL. Anda membuka SQL Server Management Studio (SSMS), memantau waktu tunggu, meninjau rencana eksekusi, mengumpulkan informasi objek, dan mulai mengoptimalkan SQL hingga Anda menjalankan mesin yang disetel dengan baik.
Jika Anda cukup mahir dalam hal itu, Anda akan mendapatkan kemenangan cepat dan kembali ke kekacauan yang dijadwalkan secara rutin. Tetapi jika Anda menyesuaikan hal yang salah, atau menyesuaikan hal yang benar ke arah yang salah, maka hari Rabu Anda telah berlalu.
Optimasi kueri SQL? Apa yang membuat Anda merasa membutuhkannya?
Sebagian besar waktu, ini adalah lonjakan tiket masalah atau keluhan pengguna. “Mengapa sistemnya sangat lambat?” pengguna Anda mengeluh. “Kami membutuhkan waktu lama untuk menjalankan laporan seperti biasa minggu ini.”
Itu deskripsi yang cukup kabur, tentu saja. Alangkah baiknya jika mereka dapat memberi tahu Anda, “Semuanya berjalan lambat karena Anda memiliki konversi implisit di baris 62 dari CurrentOrderQuery5.sql. Kolomnya adalah varchar dan Anda memasukkan bilangan bulat.” Namun sepertinya pengguna Anda tidak dapat melihat tingkat detail tersebut.
Setidaknya tiket masalah dan panggilan telepon membuat metrik aktif:mudah dikenali, mudah diukur. Ketika mereka mulai masuk, Anda dapat yakin bahwa inilah saatnya untuk penyetelan SQL.
Tetapi ada metrik pasif lain yang membuat kebutuhan menjadi kurang jelas. Hal-hal seperti penurunan penjualan, yang dapat disebabkan oleh sejumlah faktor. Apakah karena kueri yang sangat lambat di toko online Anda membuat pelanggan Anda meninggalkan keranjang belanja mereka? Apakah karena ekonomi dalam kondisi buruk?
Atau bisa juga hal-hal seperti kinerja SQL Server yang lamban. Apakah karena kueri yang ditulis dengan buruk mengirimkan pembacaan logis melalui atap? Apakah karena server kekurangan sumber daya fisik seperti memori dan penyimpanan?
Dalam kedua skenario, pengoptimalan kueri SQL dapat membantu dengan opsi pertama, tetapi tidak dengan opsi kedua.
Mengapa menerapkan solusi yang tepat untuk masalah yang salah?
Sebelum Anda melakukan pengoptimalan, pastikan bahwa penyetelan adalah solusi yang tepat untuk masalah yang tepat.
Menyetel SQL adalah proses teknis, tetapi setiap langkah teknis berakar pada naluri bisnis yang baik. Anda dapat menghabiskan waktu berhari-hari untuk mempersingkat waktu eksekusi beberapa milidetik atau mengurangi jumlah pembacaan logis hingga lima persen, tetapi apakah pengurangan tersebut sepadan dengan waktu Anda? Memang benar bahwa penting untuk memenuhi persyaratan pengguna, tetapi setiap upaya pada akhirnya mencapai titik pengembalian yang semakin berkurang.
Pertimbangkan masalah kinerja kueri SQL berikut dan konteks bisnis di sekitarnya:
- Kinerja yang dapat diterima — Kueri membutuhkan waktu 10 menit untuk dijalankan dan pengguna ingin kueri itu berjalan dalam satu menit; yang tampak seperti perbedaan yang wajar dan tujuan yang dapat dicapai untuk pengoptimalan. Namun, jika kueri membutuhkan waktu semalam dan pengguna berpikir itu harus berjalan dalam satu menit, maka itu mungkin lebih dari masalah penyetelan. Untuk satu hal, Anda mungkin harus mendidik pengguna tentang jumlah pekerjaan yang sebenarnya dilakukan kueri. Untuk alasan lain, mungkin ada masalah dengan cara database dirancang atau cara aplikasi klien ditulis.
- Utilitas — Misalkan Anda bertanggung jawab untuk mengelola database keuangan di perusahaan manufaktur. Pada akhir setiap bulan, pengguna mengeluh tentang kinerja yang buruk. Anda melacak masalahnya ke serangkaian laporan akhir bulan yang dijalankan oleh Akuntansi yang masing-masing memakan waktu berjam-jam dan langsung masuk ke lemari arsip tanpa diperiksa oleh siapa pun. Alih-alih menyetel, Anda menjelaskan masalahnya kepada manajer bisnis dan mendapatkan izin untuk menghapus laporan.
- Pergeseran waktu — Atau, anggaplah laporan yang sama penting untuk tata kelola tetapi tidak mendesak untuk bisnis. Jika dijalankan sekali per minggu atau per bulan, mereka dapat dijadwalkan di luar jam sibuk dengan melakukan pra-cache kumpulan data dan mengirimkan hasilnya ke file. Itu menghilangkan hambatan pada pengguna bisnis lain dan membebaskan pengguna Akuntansi dari keharusan menunggu laporan.
Saat Anda mempertimbangkan konteks bisnis ke dalam keputusan Anda untuk mengoptimalkan, Anda dapat menetapkan prioritas dan mengulur waktu untuk diri Anda sendiri.
Saat Anda mengoptimalkan kueri SQL, coba pembuatan diagram SQL
SSMS dan alat yang ada di dalam SQL Server menawarkan sebagian besar yang Anda butuhkan untuk pengoptimalan kueri SQL yang efektif. Gabungkan alat dengan pendekatan metodis di sekitar langkah-langkah berikut, seperti yang dijelaskan dalam e-book “Panduan mendasar untuk pengoptimalan kueri SQL“:
- Pantau Waktu Tunggu
- Tinjau Rencana Eksekusi
- Kumpulkan Informasi Objek
- Temukan Tabel Mengemudi
- Identifikasi Penghambat Kinerja
Di langkah 4, tujuan Anda adalah mengarahkan kueri dengan tabel yang mengembalikan data paling sedikit. Saat Anda mempelajari gabungan dan predikat, dan memfilter lebih awal dalam kueri daripada yang lebih baru, Anda mengurangi jumlah pembacaan logis. Itu adalah langkah besar dalam pengoptimalan kueri SQL.
Pembuatan diagram SQL adalah teknik grafis untuk memetakan jumlah data dalam tabel dan menemukan filter mana yang akan mengembalikan catatan paling sedikit. Pertama, Anda menentukan tabel mana yang berisi informasi terperinci dan tabel mana yang merupakan tabel master atau pencarian. Pertimbangkan contoh sederhana dari kueri ini terhadap database pendaftaran universitas:
Tabel detailnya adalah pendaftaran. Ini memiliki dua tabel pencarian, siswa dan kelas. Untuk membuat diagram tabel ini, gambarkan pohon terbalik yang menghubungkan tabel detail (di atas) dengan panah (atau tautan) ke tabel pencarian, seperti ini:
Sekarang, hitung jumlah relatif catatan yang diperlukan untuk kriteria gabungan (yaitu, rasio rata-rata baris yang terkait antara tabel detail dan tabel pencarian). Tulis angka di setiap ujung panah. Dalam contoh ini, untuk setiap siswa ada sekitar 5 catatan dalam tabel pendaftaran, dan untuk setiap kelas ada sekitar 30 catatan dalam pendaftaran. Itu berarti tidak perlu GABUNG lebih dari 150 (5×30) catatan untuk mendapatkan hasil untuk satu siswa atau satu kelas.
Latihan tersebut berguna jika kolom gabungan Anda tidak diindeks, atau jika Anda tidak yakin bahwa kolom tersebut diindeks.
Selanjutnya, lihat predikat pemfilteran untuk menemukan tabel mana yang akan digunakan untuk menggerakkan kueri. Kueri ini memiliki dua filter:satu pada pendaftaran dibatalkan ='N' dan yang lainnya pada tanggal_pendaftaran antara dua tanggal. Untuk melihat seberapa selektif filternya, jalankan kueri ini saat pendaftaran:
pilih count(1) dari pendaftaran dimana dibatalkan ='N'
DAN r.signup_date ANTARA :beg_date DAN :beg_date +1
Ini mengembalikan 4.344 catatan dari 79.800 total catatan dalam pendaftaran. Artinya, 5,43 persen catatan akan dibaca dengan filter itu.
Filter lainnya ada di kelas:
pilih count(1) dari kelas di mana name =‘ENGLISH 101’
Ini mengembalikan dua catatan dari 1.000, atau 0,2 persen, yang mewakili filter yang jauh lebih selektif. Jadi, kelas adalah meja penggerak, dan meja yang menjadi fokus penyetelan SQL Anda terlebih dahulu.
Suara pengguna
Jika Anda yakin memerlukan penyetelan SQL, “Panduan mendasar untuk pengoptimalan kueri SQL” menawarkan wawasan lebih lanjut. Panduan ini memandu Anda melalui lima kiat penyetelan kinerja dengan kueri salin dan tempel dan studi kasus, termasuk yang dijelaskan di atas.
Anda mungkin akan menemukan bahwa satu-satunya alat pengoptimalan kueri SQL yang paling penting adalah suara pengguna. Mengapa? Karena suara itu memberi tahu Anda kapan harus mulai mengoptimalkan dan memberi tahu Anda kapan Anda sudah cukup mengoptimalkan. Ini dapat memastikan bahwa Anda mulai mengotak-atik persneling saat perlu dan berhenti saat Anda masih di depan.
