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

115
отбором неопределенных значений. Таким образом, запрос из лис тинга 6.7 
эквивалентен запросу из лис тинга 6.12.
Листинг 6.12 

Внешнее соединение с отбором неопределенных значений
SELECT f.flight_id
FROM flight f
LEFT OUTER JOIN booking_leg bl USING (flight_id)
WHERE bl.flight_id IS NULL
План выполнения этого запроса использует антисоединение – см. рис. 6.11.
Рис. 6.11 

План выполнения для запроса из лис тинга 6.12.
Оптимизатор распознает эту конструкцию и переписывает ее на антисо-
единение. Такое поведение оптимизатора является стабильным, и на него 
можно положиться.
Когда необходимо указывать порядок 
соединения?
До сих пор оптимизатор выбирал лучший порядок соединения без какого-
либо вмешательства со стороны разработчика SQL, но так бывает не всегда.
Длинные запросы более вероятны в системах OLAP. Другими словами, 
длинный запрос, скорее всего, представляет собой аналитический отчет, 
соединяющий некоторое количество таблиц. Это количество, как может под-
твердить любой, кто работал с системами OLAP, бывает довольно внушитель-
ным. Когда количество таблиц, участвующих в запросе, становится слишком 
большим, оптимизатор больше не пытается найти лучший порядок соеди-
нения из всех возможных. Хотя рассмотрение параметров системы выходит 
за рамки этой книги, стоит упомянуть об одном из них: 
join_collapse_limit
.
Данный параметр ограничивает количество таблиц в соединении, кото-
рые будут обрабатываться стоимостным оптимизатором. Значение этого 
парамет ра по умолчанию равно 8. Это означает, что если количество таблиц 
в соединении меньше или равно восьми, оптимизатор построит планы-кан-
дидаты, сравнит их и выберет лучший. Но если количество таблиц больше 
или равно девяти, он просто выполнит соединения в том порядке, в котором 
таблицы перечислены в запросе.

---

116

Длинные запросы и полное сканирование
Почему бы не задать для этого параметра максимально возможное зна-
чение? Официального верхнего предела для этого параметра не существу-
ет, можно использовать любое целое число вплоть до максимума, равного 
2 147 483 647. Однако чем выше будет значение, которое вы зададите для это-
го параметра, тем больше времени будет потрачено на выбор лучшего плана. 
Число возможных планов, которые следует учитывать, равно факториа лу от 
количества таблиц. Таким образом, для 8 таблиц нужно сравнить сорок тысяч 
планов. Если увеличить количество таблиц до 10, придется сравнить уже три 
миллиона планов. Очевидно, что количество растет и дальше – если задать 
для параметра значение 20, общее количество планов уже выйдет за пределы 
типа integer. Один из авторов однажды наблюдал, как специалист по обра-
ботке данных изменил значение этого параметра на 30, чтобы обработать 
запрос с тридцатью соединениями. Последствия оказались плачевными – за-
прос «повис», и даже команда 
EXPLAIN
не могла вернуть результат.
С параметром легко экспериментировать, задавая значение локально на 
уровне сеанса, поэтому выполните
SET join_collapse_limit = 10
и проверьте время выполнения команды 
EXPLAIN
.
Кроме того, вспомните, что статистика таблицы недоступна для промежу-
точных результатов, а это может привести к тому, что оптимизатор выберет 
неоптимальный порядок соединения. Если разработчик SQL знает лучший 
порядок соединений, можно принудительно установить этот порядок, задав 
для 
join_collapse_limit
значение 1. В этом случае оптимизатор сгенерирует 
план, в котором соединения будут выполняться в том порядке, в каком они 
указаны в команде 
SELECT
.
Принудительно установить определенный порядок соединения можно, задав для пара-
метра 
join_collapse_limit
значение 1.
Например, если выполняется команда из лис тинга 6.13 (то есть 
EXPLAIN
для запроса из лис тинга 6.6), план выполнения на рис. 6.12 показывает, что 
соединения выполняются точно в том порядке, в котором они перечислены, 
а индекс по 
update_ts
не используется (что в этом случае отрицательно ска-
зывается на производительности).