Руководство по созданию эффективных запросов

Рис. 5.18 

Неоптимальный план выполнения короткого запроса
Вернемся к определению короткого запроса. Вначале оно казалось очень 
ясным, но теперь ситуация осложняется. Напомним, что запрос является 
коротким, если ему требуется небольшое количество строк для вычисле-
ния результатов. Действительно, в данном случае количество нужных нам 
строк невелико, но их непросто найти. Здесь необходимо пояснение: дело 
не только в том, что для короткого запроса требуется небольшое количество 
строк, но и в том, что каждая промежуточная операция также должна давать 
немного строк. Если запрос с тремя соединениями короткий, но результат 
первого соединения получился огромным – значит, что-то не так с планом 
выполнения.
Как обсуждалось ранее, единственный способ прочитать небольшое коли-
чество строк из таблицы – использовать индекс. Однако у нас нет индексов, 
которые поддерживали бы условия фильтрации в запросе из лис тинга 5.11. 

---

88

Короткие запросы и индексы
Более того, создать такой индекс невозможно, поскольку критерии выбора из 
одной таблицы зависят от значений из другой таблицы. В данном случае нет 
возможности сделать фильтрацию до соединения, что и приводит к полному 
сканированию и соединениям хешированием.
Как улучшить этот запрос? Ответ не связан напрямую с SQL. В главе 1 
сказано, что оптимизация базы данных начинается со сбора требований, 
и это тот самый случай, когда лучший путь к оптимизации лежит через сбор 
точных требований.
Обратите внимание, что в исходном запросе область поиска – это все рей-
сы с начала времен или, по крайней мере, за весь период, охваченный базой 
данных. Однако это отчет об исключительных ситуациях, который, скорее 
всего, просматривается регулярно, и, вероятно, заказчика этого отчета инте-
ресуют только недавние случаи с момента последней проверки. Более ранние 
исключения уже появлялись в предыдущих отчетах и, вероятно, уже отра-
ботаны. Следующий шаг – связаться с заказчиком этого отчета и спросить, 
будет ли соответствовать потребностям отчет, включающий только самые 
последние исключения.
Если ответ – да, то избыточный критерий отбора, который мы только что 
получили от бизнеса, можно применить к запросу. Также нам понадобится 
еще один индекс:
CREATE INDEX boarding_pass_update_ts ON boarding_pass (update_ts);
В лис тинге 5.12 показан измененный запрос исключений за два дня.
Листинг 5.12 

Запрос с добавленными избыточными критериями отбора
SELECT bp.update_ts boarding_pass_issued,
scheduled_departure,
actual_departure,
status
FROM flight f
JOIN booking_leg bl USING (flight_id)
JOIN boarding_pass bp USING (booking_leg_id)
WHERE bp.update_ts > scheduled_departure + interval '30 minutes'
AND f.update_ts >= scheduled_departure – interval '1 hour'
AND bp.update_ts >= '2020-08-16' AND bp.update_ts < '2020-08-20'
Теперь сначала будет выполнен поиск по времени, как показано в плане 
выполнения на рис. 5.19.
Время выполнения этого запроса составляет менее 200 миллисекунд; вре-
мя выполнения исходного запроса составляло 2 минуты 44 секунды.