Временная таблица против переменной таблицы

Question

У меня есть таблица, где у меня около 1,5 миллионов + результатов, которые мне нужно удалить.Раньше я использовал временную таблицу, и это приводило к тому, что журнал транзакций увеличивался в размерах довольно быстро.Проблема в том, что, как только я сделал один набор результатов, мне нужно перейти к другому, где есть еще 1,5 миллиона + результатов.Производительность этого довольно медленная, и мне интересно, стоит ли мне использовать переменную table вместо записи таблицы во временную базу данных.Я использую временную таблицу, когда выбираю начальные 1,5 миллиона записей.

Answer 1

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

Что-то вроде:

while (1=1) begin
    delete top(1000)
        from YourTable
        where ...

    if @@rowcount < 1000 break
end /* while */

Answer 2

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

Answer 3

Табличная переменная часто не подходит для таких больших наборов результатов, больше подходит для небольших чисел. Вы, вероятно, обнаружите, что данные табличной переменной в любом случае будут записаны в базу данных tempdb из-за ее размера. Лично я обнаружил, что переменные таблиц намного медленнее временных таблиц при работе с большими наборами результатов. В примере, упомянутом в конце этой статьи в SQL Server Central, где каждый раз используется 1 миллион строк в таблице, выполнение запроса с использованием временной таблицы занимало менее шестой части времени. Лично я обнаружил, что переменные таблиц часто страдают из-за производительности, когда мне приходится соединять их с реальными таблицами в запросе.

Если производительность низкая, это могут быть хотя бы частично параметры самой базы данных. Это настроено на автоматический рост? Какая у него модель восстановления?