Ще пропусна аргумента за SQL инжектиране, който е твърде добре познат и ще се съсредоточа само върху SQL аспекта на параметрите спрямо непараметрите.
Когато изпратите SQL пакет до сървъра, който и да е пакет, той трябва да бъде анализиран, за да бъде разбран. Както всеки друг компилатор, SQL компилаторът трябва да генерира AST от текста и след това оперирайте със синтактичното дърво. В крайна сметка оптимизаторът трансформира синтактичното дърво в дърво за изпълнение и накрая създава план за изпълнение, който всъщност се изпълнява. В тъмните векове от около 1995 г. имаше разлика дали пакетът беше Ad-Hoc заявка или съхранена процедура, но днес няма абсолютно никаква разлика, всички са еднакви.
Сега параметрите имат значение, че клиент, който изпраща заявка като select * from table where primary_key = @pk ще изпрати точно същия SQL текст всеки път, без значение от каква стойност се интересува. Това, което се случва тогава е, че цялата процесът, който описах по-горе, е късо съединение. SQL ще търси в паметта план за изпълнение на необработения, неанализиран текст получи (въз основа на хеш-дайджест на входа) и, ако бъде намерен, ще изпълни този план. Това означава без анализ, без оптимизация, нищо, партидата отива направо в изпълнение . В OLTP системи, които изпълняват стотици и хиляди малки заявки всяка секунда, този бърз път прави огромна разлика в производителността.
Ако изпратите заявката във формата select * from table where primary_key = 1 тогава SQL ще трябва поне да го анализира, за да разбере какво има вътре в текста, тъй като текстът вероятно е нов, различен от всяка предишна партида, която е виждал (дори единичен знак като 1 срещу 2 прави цялата партида различна). След това ще оперира върху полученото синтактично дърво и ще опита процес, наречен Опростена параметризация . Ако заявката може да бъде автоматично параметризирана, тогава SQL вероятно ще намери кеширан план за изпълнение за нея от други заявки, които са се изпълнявали преди това с други pk стойности и ще използва повторно този план, така че поне вашата заявка не трябва да бъде оптимизирана и вие пропускате стъпка за генериране на действителен план за изпълнение. Но в никакъв случай не сте постигнали пълното късо съединение, най-краткия възможен път, който постигате с истинска клиентска параметризирана заявка.
Можете да разгледате SQL Server, SQL Statistic Object
брояч на производителността на вашия сървър. Броячът Auto-Param Attempts/sec ще покаже много пъти в секунда SQL трябва да преведе заявка, получена без параметри, в автоматично параметризирана. Всеки опит може да бъде избегнат, ако правилно параметризирате заявката в клиента. Ако имате и голям брой Failed Auto-Params/sec е дори по-лошо, това означава, че заявките преминават през пълния цикъл на оптимизация и генериране на план за изпълнение.
