Вопрос возник, когда обсуждали типовую ошибку "фиктивного инкремента" или поздней фильтрации данных, когда работаем на большом объеме данных и только в конце применяем фильтрацию, хотя ее можно применить в начале скрипта.
База данных будет строить оптимально возможный план запроса из того, что ей доступно в моменте, например на сколько актуальная статистика используемых таблиц и есть ли доступные индексы.
Но движок базы также как и мы может ошибаться и запускать запрос с неоптимальным планом. и стоит вам поменять немного свой запрос самим на более оптимальное написание, движок будет предлагать более быстрый план запроса.
Также стоит понимать, что задача может решаться не в рамках одного длинного запроса, а с помощью
- временных таблиц
- промежуточных таблиц
В таком случае планировщик вам мало чем поможет и задача оптимизации будет на вас.
И тогда вопрос сохранения в эти таблицы лишних и ненужных данных встает уже сильно острее, если они на следующем шаге будут все равно отфильтрованы.
Фильтруй сначала - потом преобразовывай.
Кто пропустил, я написал целую статью по оптимизации аналитических SQL запросов - читайте здесь
#вопрос_от_ученика
