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

110

Длинные запросы и полное сканирование
Листинг 6.6 

Два полусоединения в одном длинном запросе
SELECT departure_airport, booking_id, is_returning
FROM booking_leg bl
JOIN flight f USING (flight_id)
WHERE departure_airport IN
(SELECT airport_code FROM airport WHERE iso_country = 'US')
AND bl.booking_id IN
(SELECT booking_id FROM booking WHERE update_ts > '2020-07-01')
План выполнения на рис. 6.4 показывает, что полусоединение по 
airport.
iso_country
выполняется первым. Как и в предыдущем запросе, мы использу-
ем ключевое слово 
IN
, но оптимизатор использует 
JOIN
, а не 
SEMI
JOIN
, потому 
что нет необходимости удалять дубликаты.
Рис. 6.4 

План выполнения с двумя полусоединениями
Следует отметить три момента в этом плане выполнения. Во-первых, хотя 
для получения промежуточных результатов используется доступ на основе 
индекса и мы видим, что в данном случае применяется алгоритм соедине-
ния вложенными циклами, финальное соединение основано на хеширова-
нии, потому что используется значительная часть обоих наборов данных. 
Во-вторых, полусоединение использует последовательное сканирование 
таблицы. И даже хотя таким образом мы читаем все строки из таблицы 
air-
port
, результирующее множество получается меньше, чем при объединении 
рейсов с сегментами бронирования и последующей фильтрацией по место-
положению аэропорта. Спасибо оптимизатору, который выбирает наиболее 
ограничительное полусоединение.
Наконец, хотя по столбцу 
update_ts
таблицы 
booking
есть индекс, он не ис-
пользуется, потому что условие 
update_ts
>
'2020-07-01'
охватывает почти 
половину строк таблицы.
Однако если мы изменим в этом запросе (показанном выше в лис тинге 6.6) 
критерии фильтрации и уменьшим интервал до 
update_ts
>
'2020-08-01'
, план 

---

Длинные запросы и порядок соединений 

111
выполнения радикально изменится – см. рис. 6.5. В новом плане выполнения 
видно, что фильтр по 
update_ts
теперь более ограничительный, а оптимиза-
тор отдает предпочтение индексному доступу.
Действительно ли индексный доступ к таблице 
booking
лучше в данном 
случае? Мы можем сравнить, запретив индексный доступ с помощью пре-
образования столбца 
update_ts
и переписав фильтр следующим образом: 
coalesce(update_ts,
'2020-08-03')
>
'2020-08-02'
.
Рис. 6.5 

План выполнения с двумя полусоединениями с разной селективностью
Как видно на рис. 6.6, эти действия приводят к последовательному ска-
нированию. И действительно, блокировка индекса и принудительное по-
следовательное сканирование работают лучше, чем индексный доступ на 
больших временных интервалах. По мере сокращения временного интервала 
у индексного доступа появляется преимущество. Дата 2020-08-01 оказыва-
ется переломным моментом; для всех дат, начиная с 2020-08-02, индексный 
доступ будет работать лучше.