Создание таблицы с использованием явного оператора create table в сравнении с выбором в

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

Сценарий таблицы Temp:

--- Explicitly creating temp table first and then loading.
create table #test1 (id int, name varchar(100))
insert into #test1 (id, name) select id, name from #bigTable

--- Creating temp table by selecting into.
select id,name into #test2 from #bigTable

или регулярные таблицы:

--- Explicitly creating table first and then loading.
create table test1 (id int, name varchar(100))
insert into test1 (id, name) select id, name from #bigTable

--- Creating table by selecting into.
select id,name into test2 from bigTable

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

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

http://msdn.microsoft.com/en-us/library/ms188029.aspx

Ответ 1

CREATE TABLE дает вам лучший контроль над определением таблицы перед вставкой данных, например NOT NULL, ограничениями и т.д., которые вы не можете использовать с помощью SELECT INTO.

SELECT INTO - операция с минимальной регистрацией, но INSERT..SELECT также может быть минимально зарегистрирована при некоторых условиях.
См. Руководство по эффективности загрузки данных, особенно раздел: Подведение итогов минимальных условий ведения журнала.

Вкратце, если вам не нужны ограничения и т.д. (например, вы хотите быстро создать копию таблицы), преимущество SELECT..INTO IMHO - это более короткий код.
В противном случае вы должны использовать другой способ, и вы все равно сможете его минимально зарегистрировать.

Ответ 2

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

Зависит от того, для чего вам это нужно. Я знаю, что у нас есть некоторые действия, которые SELECT ... INTO затем переименовываются, потому что он быстрее, чем обновление старой таблицы (очевидно, с большим количеством пуха для восстановления табличных объектов и т.д.).

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

В случае таблиц с индексами, insert into должен будет поддерживать индексы как часть процесса вставки. Есть и другие объекты таблицы, которые могут вызвать большую обработку, например триггеры. Насколько мне известно, в случае выбора в таблице есть голые кости, поэтому начальная производительность вставки велика. Плюс эффект транзакционного журнала минимален (упоминается в этой ссылке по вашему вопросу).

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

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

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

Ответ 3

В моем случае выполнение явного CREATE, а затем INSERT INTO заметно улучшилось как в реальном времени выполнения, так и в оценочной стоимости оптимизатором.

Моя временная таблица была не большой (8 строк), но одним из значений было вычисленное строковое значение. В некоторых случаях эта временная таблица была объединена с набором результатов с сотнями тысяч строк. Я считаю, что когда я сделал SELECT INTO для моей временной таблицы, он не выбрал оптимальный тип данных для вычисленного значения. Поэтому, когда я явно определял типы данных столбцов, используя CREATE, SQL Server смог выполнить объединение более эффективно. Конечно, этот эффект был преувеличен, потому что было задействовано столько строк.

Таким образом, казалось бы, в некоторых случаях, особенно когда один из ваших столбцов является вычисленным значением, CREATE и INSERT могут быть лучшим вариантом. Конечно, ваш пробег может варьироваться, поэтому обязательно проведите несколько тестов!