Использует ли переменные таблицы быстрее, чем временные таблицы

Question

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

Answer 1

@ Таблица может быть быстрее, так как меньше «времени установки», поскольку объект находится только в памяти.

@ Таблицы имеют много ловушек.

Вы можете иметь первичный ключ в @Table, но это все.Другие индексы Clustered NonClustered для комбинаций столбцов невозможны.

Кроме того, если ваша таблица будет содержать какие-либо реальные объемы данных (более 200, может быть, 1000 строк), то доступ к таблице будет медленнее.Особенно когда у вас, вероятно, не будет полезного индекса.

# Таблицы - боль в процессах, так как их нужно отбрасывать при отладке, их создание занимает больше времени.и они требуют больше времени для настройки, так как вам нужно добавить индексы в качестве второго шага.Но если у вас много данных, то каждый раз их #tables.

Даже в тех случаях, когда в таблице меньше 100 строк данных, вы все равно можете использовать #Tables, так как вы можете создать полезный индексна столе.

В итоге я большую часть времени использую @Tables для простоты выполнения простых процедур и т. д. Но все, что нужно выполнить, должно быть # Table.

Answer 2

Temp таблицы лучше по производительности. Если вы используете переменную таблицы и данные в переменной становятся слишком большими, SQL Server автоматически преобразует переменную в временную таблицу.

Это зависит от того, что вы пытаетесь сделать, как почти каждый вопрос, связанный с БД. Поэтому трудно ответить без дополнительной информации.

Итак, мой ответ, попробуйте и посмотрите на план выполнения. Используйте самый быстрый способ с наименьшими затратами.

• MSDN - Отображение графических планов выполнения (SQL Server Management Studio)

Answer 3

@ Таблицы не имеют статистики, поэтому план выполнения предполагает больше догадок.Отсюда рекомендуемый верхний предел в 1000 рядов.# В таблицах есть статистика, но эти могут кэшироваться между вызовами.Если ваш кардинальность значительно отличается каждый раз, когда запускается SP, вам нужно каждый раз набирать REBUILD и RECOMPILE.Конечно, это накладные расходы, но они должны быть сбалансированы с затратами на план мусора.

Оба типа будут делать IO для TempDB .

Так что нет, @Tables не панацея.