Относно разработването на софтуер и SQL ефективността - план за изпълнение

Методи и инструменти за ефективно разработване на приложения.

SQL - план за изпълнение

Преминавайки от разговори за основите на SQL към по-сложни неща, вече споменах плана за изпълнение. За да не се спирам всеки път на тази тема, ще ви разкажа повече за нея в тази статия. В крайна сметка това е нещо, което много разработчици, които са запознати с Microsoft SQL Server повече от една година, или не знаят, или не придават особено значение.

Така че днес ще покрия неща като план за изпълнение и разходи за заявки; Ще покажа с прости примери как да анализирам графичен план за изпълнение; Ще ви разкажа малко за клопките, свързани с плановете за изпълнение; Ще дам информация за по-нататъшно проучване.

План за изпълнение

Двигателят на базата данни трябва да знае в каква последователност и как да обединява таблици, какви индекси да използва и т.н. С други думи, преди да изпълните заявката, трябва да изградите (или да вземете от кеша) план за изпълнение.

Можете да видите текущия план за изпълнение в Management Studio, като натиснете „Ctrl + M“. В резултат на това, след изпълнението на партидата заявки, ще видите раздела „План за изпълнение“, който ще бъде използван по-нататък в примерите.

За да обсъдим плана за изпълнение, е необходимо поне да споменем оптимизатора на заявките - това е вътрешният механизъм на СУБД, който отговаря за изготвянето на плана за изпълнение. Опростено, той изгражда няколко планове за изпълнение и избира най-евтиния за изпълнение на конкретна заявка. В бъдеще ще се опитам да напиша статия за оптимизатора на заявките.

Също така се надявам да имате представа какво е клъстер и неклъстерирани индекси (това не е твърде важно за разбирането на статията, но ако искате да освежите паметта си, можете да прочетете раздела Проектиране на индекс).

План за изпълнение - най-простият вариант

Ето как изглежда планът за изпълнение на най-простата заявка от една таблица (задържих мишката над най-левия елемент на дървото, за да покажа информация):

Ще обясня основната информация, която е на разположение дори за толкова проста опция:

Разходи за заявка - цената на заявката в процентно изражение спрямо цялата партида заявки. По принцип това е процентът от времето, което една заявка трябва да прекара от гледна точка на оптимизатора на заявката. В този случай има само една заявка, но за анализ на няколко заявки е много полезно да разгледате техните планове за изпълнение и да определите най-скъпите (или неоправдано) скъпи.
Клъстерно сканиране на индекс - сканирането на клъстерен индекс често е предупредителен знак (Index Seek е много по-приятен за окото), но в случаи като нашия ние просто избираме всички записи от таблицата без филтър.
Очаквани разходи за поддърво - общите разходи за всички операции в дървото (или поддървото). Мога да споделя моите практически наблюдения (които не претендират, че са най-добрата истина). Ако, както в нашия случай, цената е от порядъка на 0,1 или по-малко, тогава заявката обикновено не си струва да се обръща внимание (освен, разбира се, когато има много такива заявки или няма какво повече да се оптимизира: )). Ако цената е повече от 2,0, тогава, като правило, тази заявка трябва да бъде или оптимизирана, или добра идея за това как такива заявки могат да повлияят на състоянието на системата (особено по време на пиково натоварване).

План за изпълнение на множество таблици

Сега нека разгледаме обединяването на множество таблици, което води до по-интересни и разнообразни резултати. За тези, които до този момент не са били запознати с графичния план за изпълнение, отбелязвам, че действията в плана за изпълнение се извършват отдясно наляво (и, успоредно с това, вертикално).

За да изпълните заявки, ако все още не сте забелязали, ви е необходима база данни AdventureWorks. Използвах олекотената версия за Microsoft SQL Server 2005. Другите версии могат да имат различен брой записи и плановете за изпълнение може да са различни. Понякога може да изглежда, че оптимизаторът, когато избира план, също се ръководи от позицията на планетите, но това не е така, най-често:)

Важно: SQL, както знаете, е добър именно защото скрива от вас подробностите за работата си - как точно се обединяват таблици за определена заявка и т.н. Обратната страна на монетата е, че нямаме гаранции, че заявката ще бъде изпълнена точно по начина, по който се нуждаем. Можете да използвате „съвети“, за да заобиколите това ограничение, но искам да ви предупредя - ръчно оптимизирани заявки за определен набор от данни могат да се превърнат в проблем с времето, когато разпределението на данните се промени. Ето защо, по-често, отколкото не, е по-добре да се доверите на оптимизатора, просто не забравяйте за действителната статистика за него.