SQL 2005 CTE по сравнению с Производительностью таблицы TEMP при использовании в соединениях других таблиц
Да, существует по крайней мере один такой поставщик - SQLite. Я использовал его немного, и это работает. Также можно попробовать SQL Server, Компактный . Это - встроенная база данных и имеет поставщиков EF также.
Редактирование:
SQLite имеет поддержку баз данных в оперативной памяти ( link1). Все, в чем Вы нуждаетесь, должно указать строку подключения как: "Источник данных =:memory:; Version=3; New=True";. если Вам нужно в примере, можно посмотреть SharpArchitecture.
4 ответа
Вы задаете сложный вопрос, поэтому получаете сложный ответ: это зависит от обстоятельств. (Ненавижу этот ответ.)
Но если серьезно, это связано с тем, как оптимизатор выбирает тарифный план (что вы уже знали); временная таблица или переменная похожа на постоянную структуру в том смысле, что план выполнения сначала выполняет операцию, связанную с заполнением этой структуры, а затем использует эту структуру в последующих операциях. CTE - это НЕ временная таблица; использование CTE не рассчитывается до тех пор, пока оно не будет использовано последующими операциями, и поэтому использование влияет на то, как план оптимизируется.
CTE были реализованы для повторного использования и проблем обслуживания, не обязательно для производительности; однако во многих случаях (например, рекурсия) они будут работать лучше, чем традиционные методы кодирования.
CTE - это просто псевдоним для запроса.
Он может (или не может) запускаться повторно каждый раз, когда он используется.
Нет чистого способа принудительно CTE материализация в SQL Server (например, Oracle / * + MATERIALIZE * / ), и вам придется проделывать такие грязные трюки:
CTE может улучшить производительность, если используется в планах, требующих только одной оценки (например, HASH JOIN , MERGE JOIN и т. Д.).
В этих сценариях хэш таблица будет построена прямо из CTE , тогда как использование временной таблицы потребует оценки CTE , переноса результатов в временную таблицу и повторного чтения временной таблицы.
Я обнаружил, что обычно повторяющееся CTE не дает улучшения производительности.
Так, например, если вы используете CTE для заполнения таблицы, а затем тот же CTE для присоединения в более позднем запросе , без пользы. К сожалению, CTE не являются снимками, и их буквально нужно повторять, чтобы использовать в двух отдельных операторах, поэтому они, как правило, оцениваются дважды.
Вместо CTE я часто использую встроенные TVF (которые могут содержать CTE), что позволяет правильное повторное использование, и они не лучше и не хуже, чем CTE в моих SP.
Кроме того, я также обнаружил, что план выполнения может быть плохим, если первый шаг изменяет статистику так, что план выполнения для второго шага всегда неточен, потому что он оценивается до выполнения каких-либо шагов.
В этом случае я смотрю на сохранение промежуточных результатов вручную,
Я попытался создать CTE с простым выбором с фильтром из большой таблицы Затем 3 раза запросил его.
После этого проделайте то же самое с временными таблицами.
Результат составил 70% времени для CTE -30% времени для временной таблицы. Так что временная таблица лучше для этого решения.
Я не думаю, что CTE создает временную таблицу только с выбранным запросом, но 3 раза делает выбор для большой таблицы.