Введние SQL запрос описывает результат, который необходимо получить, но не способ его получения. Набор конкретных шагов, которые сервер должен предпринять, чтобы вернуть результат называется планом выполнения запроса, его построением занимается оптимизатор. От выбора плана зависит скорость выполнения, поэтому, он является одним из самых важных элементов при анализе проблем производительности запроса. План выполнения состоит из операторов
Оконные функции и row goal
В этой заметке, я хочу описать один любопытный случай падения производительности в запросах с оконными функциями и неравномерным распределением данных. Для людей, работающих с SQL Server, использование оконных функций, как и неравномерное распределение данных – обычное и довольно частое явление, с которым периодически сталкиваешься в реальной жизни. При определенном стечении обстоятельств, два фактора соединенных вместе,
Good Enough Plan
Когда-то, я уже писал заметки на тему факторов, ограничивающих процесс оптимизации, с целью сократить его время. Это timeout и good enough plan. Особенно подробно я расписывал концепцию таймаута, сегодня я хочу рассказать про «good enough plan». Я начну с одной любопытной, на мой взгляд, истории, которую слышал от одного из членов команды разработки оптимизатора на
Cardinality Estimation Framework 2014 First Look
Введение На прошедшем мероприятии SQLSaturday #261 — Moscow 2013 я рассказывал о том, как оптимизатор оценивает предполагаемое число строк и на основании этого строит план запроса. Иными словами я говорил про оценки кардинальности, и разумеется, не смог обойти вниманием новую версию механизма оценки кардинальности в SQL Server 2014. What’s New (Database Engine) Информации на эту
Забавный случай упрощения соединений 2
Продолжая разговор, об упрощении дерева запроса, начатый в предыдущем посте, рассмотрим еще один интересный случай упрощения.
Забавный случай упрощения соединений
Недавно, просматривая план запроса, я обратил внимание, что в одной ветке плана таблицы соединяются при помощи Nested Loops Join (NL), хотя логичнее было бы видеть там Merge Join (SM). Я решил разобраться, почему так происходит и наткнулся на интересную особенность оптимизатора.
Оптимизатор без границ (ч.2)
Продолжаем отключать внутренние пороги оптимизатора. В первой части были приведены общие теоретические сведения (на которые я буду ссылаться, по этому, рекомендую их просмотреть, если еще не успели), а так же представлен флаг трассировки 8780 который устанавливает timeout в очень большое число, фактически отключая его. Осталось несколько других механизмов управляющих тем, когда происходит оптимизация и
Оптимизатор без границ (ч.1)
На недавнем мероприятии SQL Saturday 178, мне задали вопрос, можно ли сделать так, чтобы оптимизатор не прекращал оптимизацию, когда посчитает что уже нашел хороший план или наступит таймаут, а исследовал все альтернативы. Я ответил, что документированных средств нет, либо я о таких не знаю. И это действительно так, однако, возможно есть какие-то недокументированные флаги трассировки,
SQL Saturday #178 Moscow – Inside Query Optimizer
Всем добрый день, как и обещал, выкладываю материалы своего доклада на SQL Saturday. Выражаю благодарность всем организаторам, на мой взгляд все прошло хорошо (несмотря на проверку пожарной безопасности =)). К сожалению, не смог присутствовать на всех докладах, на которых хотелось бы, но там где присутствовал — было здорово. И самое главное, спасибо всем пришедшим, без
isnumeric selectivity estimation bug (en)
Some time ago on one of the forums there was a question, about why adding to the query where clause a condition «isnumeric(column)=0», makes query very slow. I did some investigations and that lead me to some interesting results.