Создание Первичного ключа на временной таблице - Когда?

Если модель восстановления вашей базы данных настроена на простую или с неполным протоколированием, SELECT ... INTO ... UNION ALL может быть самым быстрым решением. SELECT .. INTO - это массовая операция, и массовые операции минимально регистрируются.

например:

-- first, create the table
SELECT ...
INTO #TempTable
FROM MyTable
WHERE ...
UNION ALL
SELECT ...
FROM MyTable2
WHERE ...

-- now, add a non-clustered primary key:
-- this will *not* recreate the table in the background
-- it will only create a separate index
-- the table will remain stored as a heap
ALTER TABLE #TempTable ADD PRIMARY KEY NONCLUSTERED (NonNullableKeyField)

-- alternatively:
-- this *will* recreate the table in the background
-- and reorder the rows according to the primary key
-- CLUSTERED key word is optional, primary keys are clustered by default
ALTER TABLE #TempTable ADD PRIMARY KEY CLUSTERED (NonNullableKeyField) 

В противном случае у Кейда Ру был хороший совет относительно: до или после.

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

Даже более важным, чем соображения производительности, если вы не АБСОЛЮТНО, на 100% уверены, что у вас будут уникальные значения, вставленные в таблицу, сначала создайте первичный ключ. В противном случае создать первичный ключ не удастся.

Это предотвращает вставку повторяющихся / неверных данных.

If you add the primary key when creating the table, the first insert will be free (no checks required.) The second insert just has to see if it's different from the first. The third insert has to check two rows, and so on. The checks will be index lookups, because there's a unique constraint in place.

If you add the primary key after all the inserts, every row has to be matched against every other row. So my guess is that adding a primary key early on is cheaper.

But maybe Sql Server has a really smart way of checking uniqueness. So if you want to be sure, measure it!

Я не думаю, что это имеет какое-либо существенное значение в вашем случае:

• либо вы платите штраф понемногу, с каждой отдельной вставкой
• , иначе вы заплатите больший штраф после того, как все вставки будут выполнены, но только один раз

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

Но кроме этого - никакой большой разницы, правда.

Марк

Я не планировал отвечать на этот вопрос, поскольку не уверен на 100% в своих знаниях. Но поскольку это не похоже на то, что вы получаете большой отклик ...

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

Итак, если вы уверены, что ваши данные чистые (без повторяющихся данных PK), я бы сказал вставить, а затем добавьте PK.

Но если в ваших данных могут быть дубликаты данных PK, я бы сказал, сначала создайте PK, чтобы он взорвался как можно скорее.