NOT IN не является автоматически плохим условием. Нужно проверить план и особенно NULL: если подзапрос возвращает NULL, результат сравнения может стать UNKNOWN и исключить неожиданные строки.
Доводилось ли оптимизировать условие NOT IN? Насколько это плохо и как оптимизировать?
NOT IN не является автоматически плохим условием. Нужно проверить план и особенно NULL: если подзапрос возвращает NULL, результат сравнения может стать UNKNOWN и исключить неожиданные строки.
Короткий ответ
Что ответить на собеседовании
Подробный разбор
Ответ с пояснениями
NOT IN не является автоматически плохим условием. Нужно проверить план и особенно NULL: если подзапрос возвращает NULL, результат сравнения может стать UNKNOWN и исключить неожиданные строки.
Для антисоединения часто понятнее коррелированный NOT EXISTS с явным условием равенства. Но он не всегда семантически идентичен NOT IN при nullable-колонках: сначала определяют желаемую обработку NULL. Затем проверяют индексы, объём подзапроса и статистику через EXPLAIN. Замена синтаксиса без измерений не гарантирует ускорения, а изменение результата нельзя выдавать за оптимизацию.