Comments 7
Эквивалентные запросы - запросы, которые отличаются по тексту и плану выполнения, но при этом позволяют получить одинаковый результат.
Не согласен. Изрядно различные по тексту запросы вполне могут порождать абсолютно один и тот же план.
которые так же будут значительно различаться по производительности.
Все примеры сравнивают производительность на схемах, вообще не имеющих никакой индексации. На практике - так не бывает.
К слову, пример 3, в котором "с учётом порядка выполнения запроса можно ускориться почти вдвое" - это не демонстрация ускорения, а сочный такой плевок в сторону СУБД, которая оказалась неспособна нормально оптимизировать выполнение запроса. Может, статистика не набралась? хотя какая статистика, без индексов-то...
Однако не всегда студенты курсов понимают, насколько эта информация важна для формирования оптимального запроса и для качественной работы с базой данных. Даже без понимания алгоритмов объединения/сканирования/группировки, зная этот порядок выполнения, можно ускорить запрос.
Понимание декларативности SQL на много порядков важнее. На реальных системах предположение, что выполнение более-менее сложного запроса будет соответствовать описанному порядку, и соответственно попытка оптимизации запроса на этом основании, с гораздо большей вероятностью сольют производительность запроса в унитаз, а не оптимизируют его.
4. «Давайте, навесим здесь индексов…»
Индексация - это почти основа начальной оптимизации. Дальше - только тюнинг сервера и настройка построителя плана выполнения, а это и вправду высокий полёт. В реальности попытка поставить описанные в статье соображения вперёд индексной оптимизации скорее вызовет приступ нездорового смеха, чем будет воспринята как вменяемое мероприятие.
2. Distinct как решение всех проблем
Вот честно - несколько раз прочитал, но так и не понял, о чём эта глава. Даже смысла происходящего, самой логики задачи - не понял, кроме того, что их, этих логик, несколько. Сами же говорите о необходимости закрытия имеющейся вакансии бэкенд-разработчика - и тут же выбрасываете его из результата. А условие where sum_of_emp >= 1 and sum_of_sal = 100 просто заставляет вытаращить глаза от непонимания происходящего. Ну ладно с первым условием (хотя проще было отсеять незанятые вакансии в CTE), а второе-то каким ветром надуло? Неужели из тех же соображений полностью выбранной ставки?
Не согласен. Изрядно различные по тексту запросы вполне могут порождать абсолютно один и тот же план.
Согласна. Но у эквивалентных запросов могут быть и разные планы, моя ошибка. Исправлю
Все примеры сравнивают производительность на схемах, вообще не имеющих никакой индексации. На практике - так не бывает.
Во-первых, на практике очень даже бывает. Во-вторых, часто приходится работать с представлениями, которые основаны на других представлениях, поэтому в любом случае приходится думать об оптимизации запросов иным способом, не только индексами.
Индексация - это почти основа начальной оптимизации
Искренне не понимаю вашей претензии. Я в самой статье сказала, что грамотно спроектированные индексы действительно очень важны для оптимальной работы базы данных. Моя идея в том, что помимо индексации важно знать и иные темы, которые также касаются оптимизации. Плюс, опять же, не везде навесишь индексов
Вот честно - несколько раз прочитал, но так и не понял, о чём эта глава. Даже смысла происходящего, самой логики задачи - не понял, кроме того, что их, этих логик, несколько.
Идея примера была в том, чтобы отобразить список как бы актуальных должностей, на которых кто-то числится (думаю, это тоже добавлю). Идея главы: часто я среди коллег или знакомых из сферы видела, как они пытаются всюду, где появляются дубликаты, запихать distinct. Это не всегда рабочий вариант, часто дубликаты появляются потому, что запрос сам составлен некорректно
Идея примера была в том, чтобы отобразить список как бы актуальных должностей, на которых кто-то числится
Ооо... ну тогда, во-первых, действительно непонятно, зачем sum_of_sal = 100 (актуальность должности и стопроцентное освоение её бюджета - как бы не совсем синонимы),во-вторых, запрос вообще рационально построить на основании WHERE EXISTS. Что, кстати, полностью снимет потенцию появления дубликатов и необходимость в DISTINCT.
часто я среди коллег или знакомых из сферы видела, как они пытаются всюду, где появляются дубликаты, запихать distinct.
Вот насчёт злоупотреблений DISTINCT-ом согласен. Кроме случаев, когда он выполняет роль GROUP BY по всему выходному набору, в нём реально есть необходимость разве что в случаях, когда в одном выходном наборе надо совместить данные разных уровней группировки, но не ROLLUP - в этом случае оконные функции и DISTINCT зачастую эффективнее подзапросов, потому как уменьшают количество копий исходных таблиц и позволяют даже в случае фуллскана обойтись одним проходом.
часто приходится работать с представлениями
Представления чаще всего и сами по себе - песок в движке. Да, разработку упрощают, а потом лень выпиливать - вот их и тащат по продакшену. Хотя вроде никто не мешал использовать CTE.
Со статьёй в основном согласен. Навряд ли имеет смысл время выполнения приводить с точностью до микросекунд, особенно учитывая что от запуска к запуску оно будет отличаться на миллисекунды.
Скажите, методика измерения скорости выполнения какая была? Например, в третьем примере все три запроса генерируют один и тот же план и разница в производительности, скорее все, только из-за не прогретого кэша.
Проблемы студентов курсов при работе с реальными данными