Вопрос возник, когда обсуждали типовую ошибку "фиктивного инкремента" или поздней фильтрации данных, когда работаем на большом объеме данных и только в конце применяем фильтрацию, хотя ее можно применить в начале скрипта.

База данных будет строить оптимально возможный план запроса из того, что ей доступно в моменте, например на сколько актуальная статистика используемых таблиц и есть ли доступные индексы.
Но движок базы также как и мы может ошибаться и запускать запрос с неоптимальным планом. и стоит вам поменять немного свой запрос самим на более оптимальное написание, движок будет предлагать более быстрый план запроса.

Также стоит понимать, что задача может решаться не в рамках одного длинного запроса, а с помощью
- временных таблиц
- промежуточных таблиц
В таком случае планировщик вам мало чем поможет и задача оптимизации будет на вас.

И тогда вопрос сохранения в эти таблицы лишних и ненужных данных встает уже сильно острее, если они на следующем шаге будут все равно отфильтрованы.

Фильтруй сначала - потом преобразовывай.

Кто пропустил, я написал целую статью по оптимизации аналитических SQL запросов - читайте здесь

Кто я | Навигация | Обучение

#вопрос_от_ученика