2015-11-06 4 views
-1

У меня есть исходная таблица с 3 миллионами строк в sql-сервере. Первичный ключ - это встроенный sql uniqueidentifier.Sql сервер, как вставлять миллионы строк

Я хочу, чтобы скопировать все 3 миллиона строк в 4 таблицы:

Table1 имеет некоторую основную информацию, такую ​​как uniqueidentifier, book_title, book_author, book_price. Table2, Table3 и Table4 будут иметь все разные столбцы, но они будут иметь тот же первичный ключ uniqueidentifier, что и Table1, а также что первичный ключ будет внешним ключом для первичного ключа Table.

Копирование из source_table занимает много времени, потому что каждый из Table1, Table2, Table3 и Table4 имеет 50 миллионов строк. Это медленно, и я хочу улучшить производительность. Мой код ниже. У кого-нибудь есть мысли, чтобы улучшить производительность даже немного? Каждый день source_table заполняется, и я должен повторно вставить в Table1, Table2, Table3 и Table4.

Thx для ваших предложений.

insert into Table1 values (UID, book_title, book_author, book_price) 
select values (@UID, @title, @author, @price) 
from source_table 

insert into Table2 values (UID, col2, col3, col4) 
select values (@UID, @col2value, @col3value, @col4value) 
from source_table 

insert into Table3 values (UID, col2, col3, col4) 
select values (@UID, @col2value, @col3value, @col4value) 
from source_table 
+2

Почему вы должны сделать 4 копии 50 миллионов строк каждый день? В качестве побочного примечания, если у вас есть уникальный идентификатор в качестве основного ключа, я надеюсь, что у вас есть кластерный индекс на что-то еще, поскольку фрагментация достигнет почти 100% всего за пару тысяч строк. –

+0

Возможный дубликат [копирование огромных данных таблицы в другую таблицу на сервере sql] (http://stackoverflow.com/questions/5296106/copying-a-huge-table-data-into-another-table-in-sql- сервер) –

+0

Также, на DBA Stack, посмотрите, поможет ли это вам Джеймс: http://dba.stackexchange.com/questions/99367/insert-into-table-select-from-table-vs-bulk-insert – Seamus

ответ

1

Попробуйте использовать INSERT INTO ... SELECT для массовых данных импорта с минимальной Logging (см MSDN article)

Минимальное протоколирование для этого утверждения имеет следующие требования:

  • модель восстановления базы данных устанавливается на простой или объемный журнал.
  • Таблица целей пуста или непустая куча.
  • Таблица целей не используется в репликации.
  • Указатель TABLOCK указан для целевой таблицы.

    -- Temporarily set the recovery model to BULK_LOGGED. 
    ALTER DATABASE MyDB 
    SET RECOVERY BULK_LOGGED; 
    GO 
    -- You May have to drop the clustered index here 
    
    INSERT INTO INTO Table1 WITH (TABLOCK) 
        (UID, book_title, book_author, book_price) 
    SELECT UID, title, author, price) 
    FROM source_table 
    
    -- RECREATE CLUSTERED INDEX HERE 
    
    -- Reset the recovery model. 
    ALTER DATABASE MyDB 
    SET RECOVERY FULL; 
    GO 
    

    *** ТЕПЕРЬ сделать полную резервную копию

+0

спасибо за ваш вклад Стив Форд, я попробую это. Когда вы набрали '- воссоздайте кластеризованный индекс здесь'. Первичный ключ uniqueidentifier у меня есть некластеризованный. Это встроенный в sql server uniqueidentifier тип данных. Должен ли я переключиться на кластеризованный? –

+0

@JamesRodriguez Как упоминалось в других комментариях, наличие кластерного индекса на uniqueidentifier обычно плохо. Эффективно новые клавиши случайны, поэтому любая новая строка может быть вставлена ​​в любом месте на ваших существующих страницах, если вы не используете обходные методы, такие как 'newsequentialid()'. Есть некоторые обстоятельства, когда это не ужасно, но вряд ли это будет здорово. Что такое * ваш кластеризованный индекс? Мы могли бы сделать, увидев определение ваших таблиц ... –

+0

@JamesRodriguez вам следует попробовать перенести первичный ключ перед вставкой и воссоздать потом. Нет простого ответа, который вы должны тестировать с индексами и без них. –

Смежные вопросы