SQL Server: миф о предполагаемых планах выполнения
Возьмем базовый запрос:
SELECT *
FROM Production.Product AS p
JOIN Production.ProductSubcategory AS ps
ON ps.ProductSubcategoryID = p.ProductSubcategoryID
JOIN Production.ProductCategory AS pc
ON pc.ProductCategoryID = ps.ProductCategoryID
WHERE pc.Name = 'Clothing';
FROM Production.Product AS p
JOIN Production.ProductSubcategory AS ps
ON ps.ProductSubcategoryID = p.ProductSubcategoryID
JOIN Production.ProductCategory AS pc
ON pc.ProductCategoryID = ps.ProductCategoryID
WHERE pc.Name = 'Clothing';
и поместим его в среду SQL Server Management Studio . После этого нажимем комбинацию клавиш и получим Ctrl-L план выполнения - представлен на скриншоте ниже.
Предполагаемый план выполнения
Это предполагаемое выполнение. Кроме того, это и финальный план выполнения. Если вы нажмете на клавиатуре комбинацию клавиш Ctrl-M и затем выполните запрос, то получите набор результатов и следующий, уже фактический план выполнения (см. скриншот ниже).
Фактический план выполнения
В качестве графического представления плана выполнения эти два плана практически полностью совпадают. В них используются идентичные операторы, расположенные в одном и том же порядке. Это объясняется тем, что сами планы идентичны. Внутри плана выполнения инициируется один и тот же процесс оптимизации вне зависимости от того, какой план вы хотите получить — предполагаемый или фактический. Единственная возможность увидеть различие в том, что касается используемых в плане операторов, возникает в случае, когда в процессе выполнения производится рекомпиляция. Отличия статистических данных от показателей, полученных в гот момент, когда план был изначально скомпилирован как предполагаемый план, приводят к различным вариантам выбора, применяемым оптимизатором.
При очень внимательном рассмотрении вы можете заметить в упомянутых графических планах одно различие. Конвейер, представляющий поток данных между оператором Nested Loops и выполняемой в таблице ProductCategory операцией Clustered Index Seek, оказывается фактически чуть более «толстым» (см. скриншот ниже).
Отличие в размерах конвейера
Это объясняется одним из тех немногочисленных отличий, которые характеризуют предполагаемый план. В состав фактического плана обычно входит несколько метрик времени выполнения. Среднестатистический оператор, используемый в плане выполнения. обычно имеет четыре дополнительных свойства для фактического плана:
• RuntimeCountersPerThread;
• ActualRows;
• ActualEndOfScans;
• ActualExecutions.
Вот и все. Упомянутые свойства фиксируются только во время выполнения. В нашем графическом плане предполагаемое число строк составляет 1, а фактическое число — 8. Это и объясняет весьма незначительное различие в размерах конвейера. Вы можете убедиться в этом, проверив свойства оператора (см. скриншот ниже).
Свойства оператора плана
Дело не только в том, что предполагаемый и фактический планы в сущности совпадают. Если вы направите в кэш плана запрос с целью извлечения плана выполнения, то обнаружите, что план, хранящийся внутри SQL Server и раз за разом используемый для выполнения запросов, представляет собой предполагаемый план. Никаких данных, относящихся ко времени выполнения, в нем нет. Прошу понять меня правильно. Фактические планы исключительно полезны, так как содержат данные, связанные со временем выполнения. Допустим, оптимизатор полагал, что извлечет одну строку данных, а фактически извлек 100, 1000 или 1 млн строк. Так вот, знать об этом чрезвычайно важно при выполнении настройки запроса. Но остальные сведения, получаемые нами из планов выполнения, идентичны. Вот почему не следует отказываться от использования предполагаемых планов выполнения.
Планируете изучать SQL Server самостоятельно? Тогда перед этим вам необходимо пройти курсы английского (http://www.soho-bridge.ru/kursy-anglyskogo-yazyka/). Дело в том, что вся техническая документация и большинство дельных самоучителей изданы именно на английском языке.
