#sql #sql-server
#sql #sql-server
Вопрос:
Я получил запрос от analytical для автоматизации, и он содержит около 10-15 команд UNION и UNION ALL. Каждый подзапрос содержит несколько объединений больших таблиц.
Я думаю, что это будет более безопасный и оптимальный способ сохранить результаты подзапросов во временные таблицы и объединить их.
Итак, как UNION (ALL) работает на глубоком уровне? Мой способ лучше для оптимизации?
Комментарии:
1. безопасно или оптимизация?
2. Может быть, вам следует подумать о добавлении нескольких «представлений» в вашу базу данных и упростить ваш запрос?
3. Подумайте об этом — SQL — это декларативный язык. Вы сообщаете системе, что вы хотите , а не как это сделать . Если вы можете применить к своему запросу бездумное механическое преобразование, которое повышает производительность, что заставляет вас думать, что оптимизатор запросов не способен выполнить такое же преобразование?
4. Если у вас должен быть такой запрос, это звучит почти так, как будто у вас есть недостаток дизайна; особенно если все таблицы имеют одинаковые столбцы, а не разные, которые вы объединяете.
5. Вы должны протестировать его на своем оборудовании и программном обеспечении, измерить потребление ресурсов и время выполнения, решить, что для вас важнее, а затем выбрать вариант по этому критерию. DMBS довольно интеллектуальна и подходит для обработки данных.
Ответ №1:
Я не знаю, что вы подразумеваете под «безопасным», но априори нет причин разделять запрос на отдельные таблицы — если только вы не хотите запрашивать эти таблицы независимо.
Разделение результатов на отдельные таблицы имеет некоторые большие недостатки, а именно, управление дополнительными таблицами, которые вы создаете. У меня есть воспоминания о кошмарах, отслеживающих ошибки, потому что какая-то промежуточная таблица не была обновлена правильно.
В a UNION ALL подзапросы действительно изолированы друг от друга. Нет причин разбивать запросы на таблицы, чтобы сделать общий запрос более производительным.
Введение промежуточных таблиц создает сложность, поэтому для этого вам нужна веская причина. На то есть веские причины. Например, если представление используется много раз, а подзапросы стоят дорого, то их материализация делает запрос более эффективным. На самом деле, вы можете обнаружить, что индексированные представления (подход SQL Server к материализованным представлениям) являются удобным способом сделать это. Материализованные представления (как бы они ни назывались) позволяют обойти проблему устаревших промежуточных таблиц.
Комментарии:
1. Я разделил запрос на несколько таблиц — на самом деле, существенной разницы нет. На самом деле, это было даже немного медленнее. Я думаю, что может быть сложно справиться с таким длинным запросом, и именно поэтому я почувствовал сомнения, когда увидел это. Может быть, нам действительно нужно больше знать о представлениях и рассмотреть возможность их использования. Спасибо за помощь.
Ответ №2:
К сожалению, сохранение каждого подзапроса во временную таблицу на самом деле не поможет / сильно изменится с точки зрения потребления памяти. Если вы запустите полный запрос с таким количеством объединений, SQL Server будет использовать память сервера для хранения временных результатов, прежде чем предоставить окончательный набор результатов. Временные таблицы также сохраняются в памяти сервера, что означает, что объем памяти будет примерно таким же.
Для краткого комментария к UNION versus UNION ALL , если вы можете логически принять последнее вместо первого, это может повысить производительность. Это потому UNION , что само по себе означает агрегирование результатов, а также удаление дубликатов. UNION ALL не имеет такого шага удаления дубликатов, что означает, что он обычно будет превосходить обычный UNION .