Pominę argument wtrysku SQL, który jest zbyt dobrze znany i skupię się tylko na aspekcie SQL dotyczącym parametrów w porównaniu z parametrami niebędącymi parametrami.
Kiedy wysyłasz partię SQL na serwer, jakakolwiek partię, musi zostać przeanalizowana, aby została zrozumiana. Jak każdy inny kompilator, kompilator SQL musi wygenerować AST z tekstu, a następnie operować na drzewie składni. Ostatecznie optymalizator przekształca drzewo składni w drzewo wykonania i ostatecznie tworzy plan wykonania, który jest faktycznie uruchamiany. W mrocznych czasach około 1995 roku miało znaczenie, czy partia była zapytaniem Ad-Hoc, czy procedurą składowaną, ale dziś nie robi to absolutnie żadnego, wszystkie są takie same.
Teraz, gdy parametry mają znaczenie, to klient, który wysyła zapytanie, takie jak select * from table where primary_key = @pk wyśle dokładnie ten sam tekst SQL za każdym razem, bez względu na to, jaka wartość jest zainteresowana. Dzieje się wtedy tak, że cała proces, który opisałem powyżej, jest zwarty. SQL przeszuka w pamięci plan wykonania nieprzetworzonego, nieprzeanalizowanego tekstu został odebrany (na podstawie skrótu danych wejściowych) i, jeśli zostanie znaleziony, wykona ten plan. Oznacza to brak analizowania, optymalizacji, nic, partia przechodzi od razu do wykonania . W systemach OLTP, które co sekundę uruchamiają setki i tysiące małych żądań, ta szybka ścieżka ma ogromne znaczenie dla wydajności.
Jeśli wyślesz zapytanie w postaci select * from table where primary_key = 1 wtedy SQL będzie musiał przynajmniej przeanalizować go, aby zrozumieć, co jest w tekście, ponieważ tekst jest prawdopodobnie nowy, inny niż wszystkie poprzednie, które widział (nawet pojedynczy znak, taki jak 1 w porównaniu z 2 sprawia, że cała partia jest inna). Następnie będzie działać na otrzymanym drzewie składni i spróbuje wykonać proces o nazwie Prosta parametryzacja . Jeśli zapytanie może być automatycznie sparametryzowane, SQL prawdopodobnie znajdzie dla niego buforowany plan wykonania z innych zapytań, które były uruchamiane wcześniej z innymi wartościami pk i ponownie użyje tego planu, więc przynajmniej twoje zapytanie nie musi być zoptymalizowane i pominiesz krok generowania rzeczywistego planu wykonania. Ale w żadnym wypadku nie udało Ci się osiągnąć pełnego zwarcia, najkrótszej możliwej ścieżki, jaką można osiągnąć dzięki prawdziwemu zapytaniu parametrycznemu klienta.
Możesz zajrzeć do SQL Server, SQL Statistics Object
licznik wydajności twojego serwera. Licznik Auto-Param Attempts/sec pokaże wiele razy na sekundę SQL musi przetłumaczyć zapytanie odebrane bez parametrów na zapytanie automatycznie sparametryzowane. Każdą próbę można uniknąć, jeśli poprawnie sparametryzujesz zapytanie w kliencie. Jeśli masz również dużą liczbę Failed Auto-Params/sec jest jeszcze gorszy, oznacza to, że zapytania przechodzą pełny cykl optymalizacji i generowania planu wykonania.
