Въведение
SQL заявката описва очаквания резултат, а не начина за получаване на резултата. Наборът от специфични стъпки, които сървърът трябва да предприеме, за да върне резултата, се нарича план за изпълнение на заявка. Планът се изгражда от оптимизатора. Изборът на план влияе върху скоростта на изпълнение, което го прави един от най-важните елементи на анализа на проблема с ефективността на заявката.
Планът за изпълнение включва оператори и техните свойства, които са взаимосвързани помежду си под формата на дървовидна структура. Всеки оператор отговаря за отделна логическа или физическа операция. Всички заедно осигуряват резултата, описан в текста на заявката. Вътре в дървото операторите са представени от обектите на класа в паметта на SQL Server. Потребителите на сървъра (тоест вие и аз) виждат описанието, генерирано в XML формат със конкретна схема, която се показва графично от средата на SQL Server Management Studio (SSMS).
Има много различни оператори на планове и още повече имоти. Освен това от време на време се появяват нови. Тази статия не смее да опише цялото възможно разнообразие от оператори. Вместо това бих искал да споделя най-интересните допълнения в тази тема и да напомня някои стари, но полезни елементи.
Версия на сървъра
Понякога можете да намерите заявки за версията на сървъра във форумите, дори ако планът за заявка е предоставен в правилния формат (XML). Вместо това можете да спестите време и да отворите план за изпълнение като XML. И първият елемент, описващ плана, ще ви покаже версията на сървъра в свойството Build.
Този метод не позволява извличане на пълна информация за изданието на сървъра, но в повечето случаи е достатъчно, за да разберем с какво работим.
Брой редове на таблица
Вторият често задаван въпрос е „Колко редове съдържа вашата таблица?“. Тази информация може да бъде извлечена и от плана на заявката (като от версия на сървъра 2008). За целта трябва да изберем оператора за достъп до данни (Scan или Seek) на въпросната таблица и да разгледаме TableCardinality Имот. Има още едно интересно свойство, Прогнозен размер на ред за уточняване на размера на реда и приблизителна оценка на размера на таблицата или индекса (при положение, че таблицата не е компресирана).
Бих искал да отбележа, че това не е реален брой редове в таблица, а данни от статистиката на обектите. Тези данни обаче са основата за решенията, които оптимизаторът взема при изграждането на заявка.
Контекст
Планът на заявката запазва забележителни настройки на SET, за които е създаден. За да видите настройките, трябва да изберете основен елемент в плана и да разгънете Опции за настройка Имот. Например, можем да научим дали планът е изграден с ARITHABORT опцията е активирана (разликата в тази настройка често води до два различни плана и ситуации с лошо подслушване на параметри).
Брой процесори
Можем да извлечем броя на процесорите, които са налични за оптимизатора. За това трябва да отворим OptimizerHardwareDependentPropertie s -> EstimatedAvailableDegreeOfParallelism параметър в същия основен елемент и го умножете по 2. Ако е наличен само един процесор, няма нужда от умножение.
2*2 =4, налични са 4 CPU. Всъщност имам 4-ядрен процесор на моя компютър и всичките 4 ядра са налични за сървъра. Тази информация може да ви помогне да откриете машината, на която е генериран планът.
Версия на оценителя на мощността
От SQL Server 2014 станаха налични няколко версии на Cardinality Estimator (RU). Този механизъм засяга повечето решения, които оптимизаторът взема при избора на план. Можете да извлечете версията на Cardinality Estimator от CardinalityEstimationModelVersion свойство на основния оператор.
- 0 – SQL Server <=2012
- 120 – SQL Server 2014
- 130 – SQL Server 2016
- 140 – SQL Server vNext
Време за изпълнение на заявка и време за изчакване
От SQL Server 2016 SP1 действителният план за заявка включва информация за времето за изпълнение и времето на процесора. За да извлечете тези данни, трябва да разширите QueryTimeStats свойство в основния елемент и прегледайте стойностите на CpuTime и ElapsedTime . Не е необходимо да активираме събирането на време за изпълнение или да питаме „колко време е била изпълнена заявката?“ повече – цялата тази информация е включена в плана.
Второто забележително подобрение е топ 10 на най-дългите чакания по време на изпълнение на заявка. За това трябва да разширим WaitStats свойство в основния елемент. Това допълнение позволява получаване на по-точни причини за бавно изпълнение на заявка и значително опростява диагностиката.
Типове параметри
Списъкът с параметри свойството, което изброява параметрите, използвани в заявката, е съществувало в плана отдавна. Въпреки това, от SQL Server 2016 SP1, Тип данни за параметри свойството е добавено към дефиницията на параметъра. Това свойство съхранява тип данни на параметъра. Може да бъде полезно за разбиране на проблеми с преобразуването на типа.
Брой прочетени редове и приблизителен брой редове за четене
Планът за изпълнение включва две много важни свойства, действителен брой редове и прогнозен брой редове. Тези свойства съдържат информация за броя на редовете, върнати от оператора за четене на данни, но не и за броя на редовете, които той действително е прочел. Свойствата Брой на прочетените редове и Приблизителен брой редове за четене отговарят на този въпрос и позволяват извличане на броя на редовете, които сървърът действително е прочел или ще прочете. Свойството ActualRowsRead (брой редове, прочетени в SSMS) е достъпно от SQL Server 2012 SP3, 2014 SP2, 2016 SP1. EstimatedRowsRead Свойството (Прогнозен брой редове за четене в SSMS) е достъпно от SQL Server 2016 SP1.
Статистика за IO и време за изпълнение на оператора
Има няколко много полезни свойства, установени в SQL Server 2016, 2014 SP2 и налични в действителния план за заявка. Те са IO метрики (ако оператор има IO) – действителни IO статистически данни, метрики на процесора и времето за изпълнение – статистика за действителното време и метрики на паметта (от 2016 SP1, ако операторът изисква памет).
Свойствата включват следните нови показатели, които могат да бъдат разделени на нишки в случай на паралелен план:
- ActualElapsedms
- Действителни CPU
- ActualScans
- ActualLogicalReads
- ActualPhysicalReads
- ActualReadAheads
- ActualLobLogicalReads
- ActualLobPhysicalReads
- ActualLobReadAheads
- InputMemoryGrant
- OutputMemoryGrant
- UsedMemoryGrant
Както можете да видите от списъка по-горе, можете да извлечете изчерпателна информация за изпълнението на всеки даден оператор, изразходваното IO и паметта. В последните версии на SSMS тези показатели са представени в прозореца със свойства. Ако използвате стара версия на SSMS, можете да ги извлечете, като отворите план като XML. Според мен сега има всичко за показване на проценти не по прогнозна цена, а по действително изминали ресурси (създадох предложение в Connect. Така че, ако харесвате идеята, моля, гласувайте за нея).
Информация за активирани флагове за проследяване
Флаговете за проследяване в SQL Server са специални „превключватели“ от поведението на сървъра по подразбиране към някакво различно поведение. От SQL Server 2014 SP2 и 2016 SP1 информацията за активираните флагове за проследяване е налична в свойството TraceFlags на конкретния елемент. Може да включва до 100 едновременно активирани флага в момента на изграждане на заявката.
Информация за прехвърляне на данни към tempdb
Някои планови оператори, например, като Sort или Hash Match, изискват памет по време на изпълнение на заявката. Обемът на паметта обаче се изчислява в момента на компилиране. Поради различни причини (например неправилна оценка на предполагаем брой или редове), обемът на паметта може да бъде изчислен неправилно. Ако е разпределена по-малко памет, отколкото е необходима за изпълнение, сървърът ще трябва да прехвърли данни към tempdb. Това забавя изпълнението на заявката. Внимание за подобна ситуация беше въведено в сървър 2012, но от SQL Server 2012 SP3, 2014 SP2, 2016, диагностичната информация е разширена и вече включва обема на разпръснатите данни и прочетените данни. Така че можете да оцените проблема и да вземете правилните мерки.
Заключение
Планът за изпълнение включва много полезна информация, действителният план за заявка включва още повече информация, а действителният план за заявка в последните версии на SQL Server е просто мина от полезна информация. Тази статия не е предназначена да научи някого да анализира планове за заявки. Вместо това разгледах най-интересните имоти в плана, включително нови имоти и стари, но подценени. Надявам се тази статия да ви помогне следващия път, когато ще трябва да анализирате ефективността на заявката.
Статията е преведена от екипа на Codingsight с разрешението на автора.
Полезен инструмент:
dbForge Query Builder за SQL Server – позволява на потребителите да създават бързо и лесно сложни SQL заявки чрез интуитивен визуален интерфейс без ръчно писане на код.
