Почему «Выбрать * в целевой таблице из исходной таблицы» быстрее, чем «вставить в целевой таблице выбор * из исходной таблицы»

Это название вопроса. Мне любопытно узнать ответ. Кто-то сказал

Вхождение в минимально зарегистрировано в Базе данных модели простого восстановления ... Я вообще в нее не попал.

Выдержка из Microsoft:

Объем ведения журнала для SELECT ... INTO зависит от модели восстановления, действующей для базы данных. В рамках простой модели восстановления или модели восстановления с массовой регистрацией массовые операции регистрируются минимально. При минимальном ведении журнала использование оператора SELECT… INTO может быть более эффективным, чем создание таблицы с последующим заполнением таблицы оператором INSERT.

Ищу помощь

Спасибо

Пара идей / теорий:

SELECT INTO ... позволяет СУБД определять порядок сортировки на основе порядка исходной таблицы. Если вы вставляете в существующую таблицу, может потребоваться сортировка, соответствующая кластерному или некластерному индексу (-ам).

Нет индексов - если вы, SELECT INTO...СУБД, наверняка знаете, нет никаких ранее существующих индексов для обновления.

Нет конфликтов - поскольку таблица, в которую вы вставляете, не существует, SQL Server не нужно беспокоиться о блокировке на уровне строк или обработке конфликтов. Ничто другое не может ссылаться на созданную вами таблицу, так как она не существует.

Все это, как говорится, есть другие способы очень быстро вставить в таблицу.

• Убедитесь, что ваши ключи кластерного индекса совпадают, когда это возможно. Это означает, что нет сортировки на лету

• Отключить все некластеризованные индексы. Интуитивно понятный.

• Установите режим восстановления на простой и отметьте флаг 610 на ON. Используйте TABLOCKподсказку на вашей целевой таблице и NOLOCKподсказку на исходной таблице.

Например, предположим, что tablea и tableb имеют одинаковый кластеризованный индекс:

INSERT INTO TableB WITH (TABLOCK)
SELECT <Columns>
FROM TableA WITH (NOLOCK)

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

РЕДАКТИРОВАТЬ:

Вот фантастически подробный документ от MS по производительности загрузки данных в Sql Server 2008.