Коллеги, всем привет! 👋 На связи Денис.
В понедельник я показал вот этот запрос:
select t.*, d.department_id
from employees t
join departments d
on t.department_id = d.department_id
И план, в котором от таблицы DEPARTMENTS и самого JOIN не осталось ни следа.
И стало это следствием трансформации нашего запроса оптимизатором. Он применил Join Elimination (устранение соединения).
Короче говоря, оптимизатор посмотрел на запрос и понял: а зачем вообще идти в DEPARTMENTS?
Вот его логика по шагам
🔹Условие 1 - Foreign Key. Между EMPLOYEES.department_id и DEPARTMENTS.department_id есть FK-ограничение. Оптимизатор знает: для каждой строки из EMPLOYEES в DEPARTMENTS гарантированно найдется соответствующая запись.
🔹Условие 2 - мы не берем ничего нового. Колонка d.department_id, которую мы запрашиваем из второй таблицы - это тот же самый department_id, по которому идет джоин. Значение уже есть в первой таблице, дублировать смысла нет.
Вывод оптимизатора. JOIN не изменит ни количество строк, ни значения в результате. Он лишний. Убрать.
И вот тут самое интересное - оптимизатор не просто выкинул таблицу. Он ещё и добавил новый предикат, которого в исходном запросе не было:
filter("T"."DEPARTMENT_ID" IS NOT NULL)
Логика простая: INNER JOIN по определению отфильтровывает строки, где нет соответствия. Раз таблицы больше нет - оптимизатор сам добавил фильтр, который даёт тот же результат.
Вот и вся магия. Никакой мистики - просто оптимизатор сработал умнее, чем мы ожидали 🤷🏻♂️
——
Не забываем, что 13 августа в 19:00 МСК у нас пройдет вебинар по методам соединения таблиц.
Уже стало доброй традицией - самые стойкие и жадные до знаний получают еще допом интересную темку.
В этот раз будут такие:
1️⃣ Соединения в PostgreSQL - виды и как отображаются в планах.
2️⃣ Трассировка оптимизатора - как он принимает решения, на примере того самого Join Elimination, который мы сегодня разобрали.
Естественно, я расскажу ту тему, за которую проголосует большинство 🎁
Обязательно приходите и коллег своих приводите 😉
С вами был Денис. Всем предсказуемых планов запросов 🤝
#oracle #sql #оптимизация #performance #join #JoinElimination #plan #вебинар #oracledeveloper #Denis_Kivilev
Канал Oracle Developer | Чатик 💬
Мини-курс Оптимизация: Быстрый старт 🚀
📱 YouTube 📱 ВКонтакте 📱 LinkedIn 📱Threads
RUTUBE