Таблица против производительности Temp Table - PullRequest
9 голосов
/ 23 октября 2009

Что быстрее для миллионов записей: постоянная таблица или Temp Tables?

Я должен использовать это только для 15 миллионов записей. После завершения обработки мы удаляем эти записи.

Ответы [ 7 ]

15 голосов
/ 23 октября 2009

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

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

12 голосов
/ 24 октября 2009

Если вы не используете базу данных tempdb, убедитесь, что модель восстановления базы данных, в которой вы работаете, не установлена ​​на «Full». Это приведет к большим накладным расходам на этих вставках строк 50M.

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

Используйте INSERT ... WITH (TABLOCK), чтобы избежать ведения журнала на уровне строк:

INSERT INTO StagingTable WITH (TABLOCK) (.....)
SELECT .....

Аналогично для BULK INSERT. Если вы перетащите и создадите заново, создайте кластерный индекс до для вставки. Если вы не можете, вставьте сначала в одну таблицу, затем вставьте из нее в другую таблицу с правильной кластеризацией и обрежьте первую таблицу. Избегайте небольших размеров партии на BULK INSERT, если это возможно. Внимательно прочитайте документацию BULK INSERT, так как вы можете саботировать производительность неправильными опциями.

Избегайте вставки ... EXEC. Каждый ряд регистрируется.

Избегайте ОБНОВЛЕНИЙ, если только вам не нужно вычислять промежуточные итоги. Как правило, дешевле вставить из одной таблицы в другую, а затем обрезать первую таблицу, чем обновить на месте. Промежуточные вычисления являются исключением, поскольку они могут быть выполнены с помощью UPDATE и переменных для накопления значений между строками.

Избегайте табличных переменных ни для чего, кроме управляющих структур, поскольку они предотвращают распараллеливание. Не присоединяйте свою таблицу строк 50M к переменной таблицы, вместо этого используйте временную таблицу.

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

Не пытайтесь делать слишком много в одном утверждении.

2 голосов
/ 23 октября 2009

Постоянная таблица быстрее, если структура таблицы должна быть одинаковой на 100%, поскольку нет никаких накладных расходов для распределения пространства и построения таблицы.

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

0 голосов
/ 07 декабря 2018

Это зависит.

Временные таблицы хранятся в базе данных tempdb, которая может быть, а может и не находиться на диске, отличном от вашей фактической базы данных. Так что многое зависит от а) скорости этих дисков и б) от того, какие базы данных / файлы находятся на одном диске.
(например, ваша фактическая база данных будет быстрее, если файлы базы данных и файлы журналов находятся на разных физических дисках)


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

Таким образом, если вы вставите 15 миллионов записей в таблицу, обработаете их (возможно, с большими обновлениями для всех из них) и впоследствии удалите их, SQL Server должен немедленно распространить все эти изменения по сети на зеркальный сервер.

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

0 голосов
/ 23 октября 2009

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

0 голосов
/ 23 октября 2009

Постоянная таблица в большинстве случаев быстрее, чем временная таблица.

Посмотрите: http://www.sql -server-performance.com / Articles / Per / Derve_temp_tables_p1.aspx

0 голосов
/ 23 октября 2009

Временные таблицы находятся в памяти (если они не слишком большие), поэтому теоретически они должны быть ДЕЙСТВИТЕЛЬНО быстрыми Но обычно это не так. Как правило, старайтесь держаться подальше от временных таблиц, если только это не единственное решение. Можете ли вы дать нам больше информации о том, что вы пытаетесь сделать? Возможно, это можно сделать с помощью производного запроса

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...