Временная таблица SQL Server 2000 против табличной переменной

Question

Что было бы более эффективно при хранении некоторых временных данных (50 тыс. Строк в одном и 50 тыс. В другом) для выполнения расчета прихода. Я буду делать этот процесс один раз, каждую ночь.

Как вы проверяете эффективность при сравнении чего-то подобного?

Answer 1

Результаты будут различаться в зависимости от того, что будет легче хранить данные, на диске (#temp) или в памяти (@temp).

Несколько выдержек из ссылок ниже

• Временная таблица создается и заполняется на диске в системной базе данных tempdb.
• Переменная таблицы создается в памяти и поэтому работает немного лучше, чем таблицы #temp (также потому, что в табличной переменной еще меньше блокировок и журналирования). Переменная таблицы может по-прежнему выполнять ввод-вывод в базу данных tempdb (именно здесь возникают проблемы с производительностью таблиц #temp), хотя в документации об этом не говорится явно.
• Переменные таблицы приводят к меньшему количеству перекомпиляций хранимой процедуры по сравнению с временными таблицами.
• [Y] Вы можете создавать индексы для временной таблицы, чтобы повысить производительность запросов.

Относительно вашего конкретного случая с 50k строк:

По мере увеличения размера ваших данных и / или увеличения повторного использования временных данных вы обнаружите, что использование таблиц #temp имеет больше смысла

Ссылки:

• Должен ли я использовать таблицу #temp или переменную @table?
• MSKB 305977 - SQL Server 2000 - Переменные таблицы

Answer 2

Может быть большая разница в производительности между использованием табличных переменных и временных таблиц. В большинстве случаев временные таблицы работают быстрее, чем переменные таблицы. Я взял следующий совет из частной группы новостей SQL Server MVP и получил разрешение от Microsoft поделиться им с вами. Один из MVP заметил, что, хотя запросы с использованием табличных переменных не генерировали параллельные планы запросов для большого блока SMP, аналогичные запросы, использующие временные таблицы (локальные или глобальные) и выполняющиеся в тех же условиях, генерировали параллельные планы.

Больше от SQL Mag (к сожалению, требуется подписка, я постараюсь найти дополнительные ресурсы на мгновение)

РЕДАКТИРОВАТЬ : Вот еще более подробная информация из CodeProject