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

Question

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

Сценарий временной таблицы:

--- 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

Answer 1

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

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

Вкратце, если вам не нужны ограничения и т. Д.хотите быстро создать копию таблицы) преимущество SELECT..INTO ИМХО заключается в более коротком коде.В противном случае вы должны использовать другой способ, и вы все равно сможете его минимально регистрировать.

Answer 2

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

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

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

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

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

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

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

Answer 3

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

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

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