Заметки Дмитрия Пилюгина о Microsoft SQL Server 

Twitter RSS
formats

USE HINT и ASSUME_MIN_SELECTIVITY_FOR_FILTER_ESTIMATES

В одной из предыдущих заметок мы говорили о таком механизме как Cardinality Estimator.

Cardinality Estimation, СЕ (оценка кардинальности) – это оценка предполагаемого числа строк, которое будет обработано тем или иным оператором запроса. Оценка – один из ключевых факторов при построении плана запроса. Оценку числа строк осуществляет компонент Cardinality Estimator.

Хинт ASSUME_MIN_SELECTIVITY_FOR_FILTER_ESTIMATES контролирует один из аспектов поведения этого компонента, а именно, оценку комплексных предикатов. На сегодняшний день SQL Server имеет три алгоритма оценки подобных предикатов:

  • оценка по предположению независимости
  • оценка по минимальной селективности
  • оценка по алгоритму exponential backoff

Удобнее всего будет разобрать их на примере.

Читать далее…

 
formats

USE HINT и DISABLE_PARAMETER_SNIFFING

Прослушивание параметров — это прием оптимизации, который позволяет использовать значения параметров модуля (например, хранимой процедуры или функции), во время первого вызова, для оценки предполагаемого числа строк при построении плана.

Прослушивание параметров в большинстве случаев полезная вещь, но эта техника плохо работает если значения параметров сильно отличаются по селективности. Например, в случае если для одного значения параметра выбирается 99% строк таблицы, а для второго 1% — серверу может быть выгодно использовать разные планы. Один план будет более эффективен для большего числа строк, второй для меньшего.

Однако, если работает прослушивание параметров, план будет построен для того значения, что было передано при первом вызове. Если для этого значения выбирается небольшое число строк, будет построен план выгодный для получения небольшого числа строк. Когда значение параметра изменится так, что процедура должна будет вернуть гораздо больше строк, план останется «старым», эффективным для небольшого числа строк. Давайте рассмотрим простой пример, который иллюстрирует проблему.

Читать дальше…

 
formats

USE HINT и ENABLE_QUERY_OPTIMIZER_HOTFIXES

Оптимизатор запросов, это компонент SQL Server, который отвечает за то, как именно будет выполняться запрос. Это довольно сложный механизм, и разработчики, которые его пишут, не застрахованы от ошибок. Сложность в исправлении ошибок оптимизатора заключается в том, что даже если найдена ошибка, приводящая к неэффективному плану, нельзя ее просто исправить. Исправление этой ошибки для какого-то проблемного запроса или типа запросов, может привести к смене плана выполнения в тех запросах, которые до это не испытывали проблем. По этой причине разработчики оптимизатора очень консервативны при внесении исправлений в оптимизатор. Очень часто, внеся исправления, они оставляют их по умолчанию выключенными, чтобы, если вы не испытываете проблем, вы их не заметили, и они никак не повлияли на производительность вашего приложения (исключение составляют серьезные ошибки, например, те, которые могут вести к неверным результатам). В то же время, если у вас есть проблемы, вы могли бы включить эти исправления и получить нужный эффект.
Читать дальше…

 
formats

USE HINT и FORCE_LEGACY/DEFAULT_CARDINALITY_ESTIMATION

Cardinality Estimation, СЕ (оценка кардинальности) – это оценка предполагаемого числа строк, которое будет обработано тем или иным оператором запроса. Оценка – один из ключевых факторов при построении плана запроса (более подробно я рассматривал эту тему в докладе кардинальность и планы выполнения). Оценку числа строк осуществляет компонент Cardinality Estimator.

До 2014 сервера, была всего одна версия этого компонента, разработанная для SQL Server 7.0, постепенно адаптируемая к новым версиям, но принципиально не меняющаяся. Со временем, разработчики сиквела поняли, что старую модель больше развивать нельзя – ее трудно расширять, трудно тестировать, любые изменения в одном месте могут приводить к поломкам в другом, кроме того, те предположения о реальности, которые были верны во времена SQL Server 7.0, сейчас устарели.

Начиная с SQL Server 2014 у сервера появилась новая модель оценки строк, адаптированная к современным рабочим нагрузкам. Эта модель оценки имеет новую архитектуру, расширяема и дополняема, версия этой модели получила номер 120 (по аналогии с уровнем совместимости БД, соответствующим серверу 2014 – 120). В 2016 сервере современная модель была расширена и получила номер версии 130, при этом версия 120 сохранилась. В еще не вышедшем, на момент написания статьи, RTM сервере vNext уже есть модель версии 140.

Читать дальше

 
formats

USE HINT и DISABLE_OPTIMIZED_NESTED_LOOP

Один из доступных алгоритмов соединения двух таблиц в SQL Server это вложенные циклы (Nested Loops). В зависимости от выбранного оптимизатором порядка соединения таблиц, одна из таблиц выбирается как внешняя (по ней открывается внешний цикл), вторая как внутренняя (для каждой строки из внешней таблицы выполняется внутренний цикл по второй таблице), во время соединения, внутри циклов проверяется условие соединение, такой подход называется «наивный» алгоритм вложенных циклов. Если же по внутренней таблице доступен индекс по условию соединения, то необязательно выполнять внутренний цикл проверки по каждой строке второй таблицы, вместо этого, можно передать в качестве аргумента поиска значение из внешней таблицы, а все строки, что будут найдены во внутренней таблице соединить со строкой из внешней таблицы.

Поиск по внутренней таблице — это случайный доступ, SQL Server начиная с версии 2005 имеет оптимизацию, называемую batch sort (не путать с оператором Sort в Batch Mode для колоночных индексов). Идея оптимизации заключается в том, чтобы перед тем, как получить данные из внутренней таблицы, упорядочить ключи поиска из внешней, превратив тем самым случайный доступ в последовательный.
Читать дальше…

 
formats

USE HINT и новые указания запросов в SQL Server 2016 SP1

«Query Hints» в документации переводится как «указания запросов», кто-то называет их «подсказками», но чаще говорят просто «хинты». Я буду использовать в заметке именно последнее выражение, т.к. оно более распространено в повседневной жизни и сразу дает понять, о чем идет речь. Эта публикация — введение, она открывает цикл заметок по новым хинтам, которые появились в SQL Server 2016 SP1.

Читать дальше…

 
formats

Что можно узнать из плана запроса

Введние

SQL запрос описывает результат, который необходимо получить, но не способ его получения. Набор конкретных шагов, которые сервер должен предпринять, чтобы вернуть результат называется планом выполнения запроса, его построением занимается оптимизатор. От выбора плана зависит скорость выполнения, поэтому, он является одним из самых важных элементов при анализе проблем производительности запроса.

План выполнения состоит из операторов и их свойств, связанных между собой в древовидную структуру, каждый из которых отвечает за определенную логическую и физическую операцию. Все вместе они обеспечивают получения того результата, который описан текстом запроса. Внутри сервера операторы представляют собой объекты классов в памяти SQL Server. Пользователи сервера, т.е. мы с вами, видим их описание, сформированное в виде документа XML с определенной схемой, и отображаемое средой SQL Server Management Studio (SSMS) в графическом виде.

Существует множество разнообразных операторов плана, а их свойств еще больше, кроме того, периодически появляются новые. Эта заметка не ставит целью описать всё возможное многообразие операторов, вместо этого, я хотел бы поделиться наиболее интересными добавлениями в этой области, а также вcпомнить некоторые старые, но полезные элементы.

Читать дальше…

 
formats

Возобновляю публикации в русскоязычном блоге

В 2014 году, я начал вести англоязычный блог www.queryprocessor.com, пообещав не забрасывать свой первоначальный блог и продолжать публиковать в нем статьи по мере сил и возможностей. С тех пор, мужественно и последовательно, за 2.5 года я не опубликовал в нем ни одной статьи. Хватит это терпеть!

Появились интересные вещи, которыми бы я хотел поделиться с читателями, кроме того, я просто соскучился по написанию статей на русском языке, поэтому, я решил возобновить публикацию статей в этом блоге. На этот раз я не буду ничего обещать, посмотрим, как пойдет.

 
formats

QueryProcessor.com

I’m glad to say, that I started the English version of my blog called www.QueryProcessor.com, where I’m going to publish my notes about Query Optimization and Query Execution in SQL Server.

This will help me to learn English better and share my experience with more readers!

Welcome everybody!

Рад сообщить, что я запустил английскую версию своего блога www.QueryProcessor.com!
Новый блог будет целиком и полностью посвящен обработке запросов в SQL Server, это включает в себя компоненты Query Optimization и Query Execution.

Это позволит мне лишний раз поупражняться в английском языке и рассказать про оптимизацию запросов более широкому кругу читателей.

Это не зеркало русского блога. Я не буду публиковать там старые заметки или их переводы. Что касается новых заметок — то материал прежде всего будет попадать туда, и в зависимости от свободного времени, постараюсь дублировать материал на русском тут.

Всем welcome!

 

 
formats

Оконные функции и row goal

blogpost_min

В этой заметке, я хочу описать один любопытный случай падения производительности в запросах с оконными функциями и неравномерным распределением данных. Для людей, работающих с SQL Server, использование оконных функций, как и неравномерное распределение данных – обычное и довольно частое явление, с которым периодически сталкиваешься в реальной жизни. При определенном стечении обстоятельств, два фактора соединенных вместе, могут стать источником низкой производительности.

 

 

Читать дальше…

 
 Share on Facebook Share on Twitter Share on Reddit Share on LinkedIn
Комментарии отключены  comments