Saya akan melewatkan argumen SQL Injection, yang terlalu terkenal dan hanya fokus pada aspek SQL parameter vs. non parameter.
Saat Anda mengirim kumpulan SQL ke server, kumpulan apa pun, itu harus diuraikan untuk dipahami. Seperti kompiler lainnya, kompiler SQL harus menghasilkan AST dari teks dan kemudian beroperasi pada pohon sintaks. Pada akhirnya pengoptimal mengubah pohon sintaks menjadi pohon eksekusi dan akhirnya menghasilkan rencana eksekusi dan itu benar-benar dijalankan. Kembali ke zaman kegelapan sekitar tahun 1995, ada perbedaan jika kumpulan itu adalah kueri Ad-Hoc atau prosedur tersimpan, tetapi hari ini sama sekali tidak ada, semuanya sama.
Sekarang di mana parameter membuat perbedaan adalah bahwa klien yang mengirim kueri seperti select * from table where primary_key = @pk akan mengirim teks SQL yang sama persis setiap saat, tidak peduli nilai apa yang diminati. Apa yang terjadi kemudian adalah seluruh proses yang saya jelaskan di atas adalah hubungan pendek. SQL akan mencari di memori rencana eksekusi untuk teks mentah, tidak diuraikan, itu diterima (berdasarkan intisari hash dari input) dan, jika ditemukan, akan menjalankan rencana itu. Itu berarti tidak ada penguraian, tidak ada pengoptimalan, tidak ada apa-apa, kumpulan langsung ke eksekusi . Pada sistem OLTP yang menjalankan ratusan dan ribuan permintaan kecil setiap detik, jalur cepat ini membuat perbedaan kinerja yang besar.
Jika Anda mengirim kueri dalam bentuk select * from table where primary_key = 1 maka SQL setidaknya harus menguraikannya untuk memahami apa yang ada di dalam teks, karena teks tersebut kemungkinan adalah teks baru, berbeda dari kumpulan sebelumnya yang terlihat (bahkan satu karakter seperti 1 vs. 2 membuat seluruh batch berbeda). Kemudian akan beroperasi pada pohon sintaks yang dihasilkan dan mencoba proses yang disebut Parameterisasi Sederhana . Jika kueri dapat diparemeterisasi secara otomatis, maka SQL kemungkinan akan menemukan rencana eksekusi yang di-cache untuknya dari kueri lain yang berjalan sebelumnya dengan nilai pk lain dan menggunakan kembali paket itu, jadi setidaknya kueri Anda tidak perlu dioptimalkan dan Anda melewatkan langkah menghasilkan rencana eksekusi yang sebenarnya. Namun tidak berarti Anda mencapai korsleting lengkap, jalur sesingkat mungkin yang Anda capai dengan kueri berparameter klien yang sebenarnya.
Anda dapat melihat SQL Server, Objek Statistik SQL
penghitung kinerja server Anda. Penghitung Auto-Param Attempts/sec akan menunjukkan berkali-kali per detik SQL harus menerjemahkan kueri yang diterima tanpa parameter menjadi parameter otomatis. Setiap upaya dapat dihindari jika Anda membuat parameter kueri dengan benar di klien. Jika Anda juga memiliki jumlah Failed Auto-Params/sec yang tinggi bahkan lebih buruk lagi, itu berarti kueri menjalani siklus penuh pengoptimalan dan pembuatan rencana eksekusi.
