Какие из них имеют лучшую производительность: производные таблицы или временные таблицы

Question

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

Answer 1

Производная таблица является логической конструкцией.

Он может храниться в tempdb, построенном во время выполнения, переоценивая базовый оператор каждый раз, когда к нему обращаются, или даже оптимизируется вообще.

Временная таблица - это физическая конструкция. Это таблица в tempdb, которая создается и заполняется значениями.

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

Например, CTE (общие табличные выражения) в SQL Server могут (и, скорее всего, будут) переоцениваться при каждом их использовании. Этот запрос:

WITH    q (uuid) AS
        (
        SELECT  NEWID()
        )
SELECT  *
FROM    q
UNION ALL
SELECT  *
FROM    q

будет наиболее вероятно даст два разных NEWID().

В этом случае следует использовать временную таблицу, поскольку она гарантирует, что ее значения сохранятся.

С другой стороны, этот запрос:

SELECT  *
FROM    (
        SELECT  *, ROW_NUMBER() OVER (ORDER BY id) AS rn
        FROM    master
        ) q
WHERE   rn BETWEEN 80 AND 100

лучше с производной таблицей, потому что использование временной таблицы потребует извлечения всех значений из master, в то время как это решение будет просто сканировать первые 100 записи с использованием индекса id.

Answer 2

Зависит от обстоятельств.

Преимущества производных таблиц:

1. Производная таблица является частью большего одиночного запроса и будет оптимизирована в контексте остальной части запроса. Это может быть преимуществом, если оптимизация запросов помогает повысить производительность (как правило, за некоторыми исключениями). Пример: если вы заполняете временную таблицу, а затем используете результаты во втором запросе, вы фактически привязываете механизм базы данных к одному методу выполнения (запустите первый запрос полностью, сохраните весь результат, выполните второй запрос), где с помощью производной таблицы оптимизатор сможет найти более быстрый метод выполнения или путь доступа.

2. Производная таблица «существует» только с точки зрения плана выполнения запроса - это чисто логическая конструкция. Там действительно нет таблицы.

Преимущества временных таблиц

1. Таблица «существует», то есть материализована в виде таблицы, по крайней мере, в памяти, которая содержит набор результатов и может использоваться повторно.

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

Answer 3

Я хочу добавить анекдот здесь, так как это заставляет меня советовать противоположность принятого ответа. Я согласен с мнением, представленным в принятом ответе, но оно в основном теоретическое. Мой опыт побудил меня рекомендовать временные таблицы по производным таблицам, общим табличным выражениям и функциям табличных значений. Мы широко использовали производные таблицы и общие выражения таблиц с большим успехом, основываясь на мыслях, согласующихся с принятым ответом, пока не начали работать с большими наборами результатов и / или более сложными запросами. Затем мы обнаружили, что оптимизатор не очень хорошо оптимизировал производную таблицу или CTE.

Я посмотрел сегодня пример, который побежал за 10:15. Я вставил результаты из производной таблицы в временную таблицу и соединил временную таблицу в основном запросе, и общее время сократилось до 0:03. Обычно, когда мы видим большую проблему с производительностью, мы можем быстро решить эту проблему. По этой причине я рекомендую временные таблицы, если ваш запрос не является относительно простым, и вы уверены, что он не будет обрабатывать большие наборы данных.

Answer 4

Большая разница в том, что вы можете поместить ограничения, включая первичный ключ, во временную таблицу. Для больших (я имею в виду миллионы записей) иногда вы можете получить лучшую производительность с временным. У меня есть ключевой запрос, который нуждается в 5 объединениях (каждое объединение оказывается похожим). Производительность была в порядке с 2 соединениями, а затем на третьем производительность пошла плохо, и план запросов сошел с ума. Даже с подсказками я не смог исправить план запроса. Попытка реструктуризации объединений в виде производных таблиц с сохранением проблем с производительностью. С помощью временных таблиц можно создать первичный ключ (тогда, когда я заполняю первую сортировку на ПК). Когда SQL мог объединить 5 таблиц и использовать PK, производительность возросла с минут до секунд. Хотелось бы, чтобы SQL поддерживал ограничения для производных таблиц и CTE (даже если только PK).