Сергей Михалев - Оптимизация SQL-запросов, часть 1

Рет қаралды 59,341

11 жыл бұрын

Сергей Михалев, VIAcode - Оптимизация SQL-запросов, часть 1
Встреча CodeFreeze в Петербурге, 28.08.2013
В среду, 28 августа в бизнес-инкубаторе «Ингрия» состоялась встреча с разработчиком компании VIACode Сергеем Михалевым. Из доклада слушатели узнали о том, какие проблемы с производительностью могут возникнуть при работе с самыми, казалось бы, обыкновенными SQL-запросами и об оптимизации этих запросов.
По ходу доклада мы последовательно рассмотрим несколько весьма непростых ситуаций, все глубже и глубже вникая в область оптимизации запросов. Для этого нам потребуется определённый уровень понимания устройства и работы SQL Server-а, а также глубокие знания в области оптимизации запросов. Несмотря на то, что основой для примеров служит MS SQL, многие аспекты могут быть применены и к другим СУБД.
Мы разберемся с такими вопросами как:
- жизненный цикл запросов - механизм подготовки, кеширования и исполнения запросов в MS SQL;
- основы чтения планов выполнения запросов;
- влияние внешних ключей, кластерных представлений и вычислимых столбцов на производительность запроса;
- проблема неявного преобразования типов;
- статистика сервера и как она может влиять на скорость исполнения запроса.
Материал для доклада собран из реальных проектов и задач. Многие примеры выстраданы долгими часами, днями (а то и месяцами) напряженной работы. Доклад будет полезен всем, кто работает с базами данных.

Пікірлер: 36

@illusion001video 3 жыл бұрын

Отличное выступление. Спасибо!

@user-le1sv5hy3c 10 жыл бұрын

Спасибо, Сергей, взял на заметку трюк с OUTER APPLY!

@user-wc8ii2rr3v 10 жыл бұрын

Спасибо за замечание. Действительно сталкивался я с этим параметром. Но реально никогда его не менял. Просто потому, что протестировать действительный эффект на работающем продакшене и просчитать последствия практически невозможно. Так воздействие ведеться сразу на все запросы. И это возможно будет работать быстрее в тестировании, но обычно на продакшене машиша мощнее и не ясно, как это может сказаться там.

@antonxxx3685 Ай бұрын

Сикл ))) спасибо, поржал)

@aensidhe 10 жыл бұрын

Про параллелизм: есть параметр cost threshold for parallelism (подробнее в MSDN, ютуб не дали приложить ссылку). С её помощью можно менять порог "последовательный план недостаточно быстрый". Это необходимо, т.к. фактически, есть системы, в которых параллельные планы реально медленнее последовательных. Многие рекомендуют его повышать, если система скорее всего не требует параллелизма (например, OLTP-системы).

@iklova 10 жыл бұрын

Сергей, спасибо большое за обучение. Очень доходчиво подаете информацию. Получил много полезного. Но не акцентируйте, пожалуйста, внимание на том, что parameter sniffing это плохо. Наоборот необходимо использовать запросы без явного указания значений фильтрации. Это в большинстве случаев ускорит отработку запросов, т.к. в плане уже будет готов результат и не нужно каждый раз компилить. Использовать изменённый запрос нужно лишь тогда, когда действительно в этом есть большая необходимость, кода СУБД действительно промахивается.

@user-wc8ii2rr3v 10 жыл бұрын

Спасибо, согласен, что PS может быть в 90% случаев полезен, особенно для простых запросов. Но мы же обсуждали оптимизацию, о которой даже Кнут говорил, что преждевременная оптимизация - корень всех зол. Поэтому да, для простых запросов об этом забодиться не стоит, но вот для тех 10%, которые представляют интерес с точки зрения оптимизации забывать нельзя. Поэтому PS - это не хорошо и не плохо, это поведение, которое иногда ведет к очень загадочным последствиям. :)

@Grizlek 7 жыл бұрын

интересная лекция. спасибо.

@miheygm1512 4 жыл бұрын

Сергей, Вы говорите что оптимизатор использует хороший план, но не лучший. Т.к. никому не нужно, чтобы план был самым лучшим и запрос выполнялся очень быстро, но при этом сам план строился 10 секунд. Вот у меня такой вопрос, можно ли ради эксперимента настроить оптимизатор так, чтобы он увеличил время на выбор оптимального плана?

@elenelenaelena8846 8 жыл бұрын

Пожалуйст подскажите ссылку на документацию (для разговора с начальством) в подтверждении ваших слов о важности наличия foreign key для оптимизации запроса вы говорите: "хотя если бы он знал, что эта запись всегда одна, он бы выбросил этот кластеред индекс seek и просто ограничился бы по одному пробегу по табличке диагнозов"

@user-wc8ii2rr3v 8 жыл бұрын

К начальству нельзя с документацией, к нему нужно с результатами ваших performance test-ов. Нужно понимать, что FK помогают при селектах. Но они так же требуют усилий для поддержания. Поэтому для баз данных в которых преобладают insert/update/delete - их часто не используют специально.

@samiraxmedov3394 Жыл бұрын

как хорошо запомнить синтаксис?

@user-ps1uz6ec1j 7 жыл бұрын

Сергей, зачем нужно в ваших примерах указывать оптимизатору, что во втором потоке может быть максимум одна строка через outer apply, group by, кластерное вью, если в итоге данные из второго потока просто не используются и поэтому план становится лучше. Такого же результата можно добиться просто убрав второй поток из запроса. Зачем Вы проводите все эти манипуляции? Какой в них смысл?

@user-wc8ii2rr3v 7 жыл бұрын

Ситуация в этом конкретном примере была в том, что одна и та же функция использовалась в разных контекстах: когда вытаскивались поля и когда считался count(*). А самый главный вывод - он в самом конце, вы должны точно понимать, что вы хотите объяснить оптимизатору и какие у вас для этого есть инструменты.

@user-bl4pz7pm3z 5 жыл бұрын

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

@user-et1ke7wn8n 4 жыл бұрын

Речь идёт про count.

@Pankin13 8 жыл бұрын

не совсем понял про 4 пункт добавление комментариев - при добавлении комментария sql думает что это уже другой запрос?

@user-wc8ii2rr3v 8 жыл бұрын

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

@user-ny2ys8dy7w 5 жыл бұрын

@@user-wc8ii2rr3v, я вот не понял как менять этот комментарий на каждом следующем вызове :/

@user-oc5sd1jw4n 4 жыл бұрын

@@user-ny2ys8dy7w я тож не понял

@0992timik 8 жыл бұрын

актуально ли это для PostgreSQL?

@user-wc8ii2rr3v 8 жыл бұрын

В PostgreSQL совсем другой оптимизатор, общие мысли возможно помогут. Но имея небольшой, но все-таки опыт оптимизации и в PostgreSQL - там все по-другому и рычаги влияния на оптимизатор тоже.

@user-oz5gr3zc7n 3 жыл бұрын

А для какой СУБД это вообще актуально?..

@user-le1sv5hy3c 10 жыл бұрын

"nested looD" на 30-м слайде :)