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

Это зависит от многого.

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

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

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

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

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

eg:

-- 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% уверены, что в таблицу будут вставлены уникальные значения, сначала создайте первичный ключ. В противном случае создать первичный ключ не удастся.

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

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

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

Но, возможно, у Sql Server есть действительно умный способ проверки уникальности. Так что, если хочешь быть уверенным, измерь!

Мне было интересно, могу ли я улучшить очень-очень «дорогую» хранимую процедуру, влекущую за собой кучу проверок при каждой вставке в таблицы, и наткнулся на этот ответ. В Sproc открыто несколько временных таблиц, которые ссылаются друг на друга. Я добавил первичный ключ в оператор CREATE TABLE (хотя в моем выборе используются операторы WHERE NOT EXISTS для вставки данных и обеспечения уникальности), и мое время выполнения было СОВЕРШЕННО сокращено. Я настоятельно рекомендую использовать первичные ключи. Всегда хотя бы пробуйте это делать, даже если думаете, что вам это не нужно.

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

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

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

Но в остальном - нет особой разницы.

Марк

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

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

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

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

Когда вы добавляете PK при создании таблицы - проверка вставки равна O(Tn) (где Tn - это «n-е треугольное число», то есть 1 + 2 + 3 ... + n), потому что когда вы вставляете x-ю строку, она проверяется на соответствие ранее вставленным строкам «x - 1».

Когда вы добавляете PK после вставки всех значений - проверяется O(n^2), потому что, когда вы вставляете x-ю строку, она проверяется на соответствие всем n существующим строкам.

Первый, очевидно, быстрее, поскольку O(Tn) меньше O(n^2)

P.S. Пример: если вы вставляете 5 строк, это 1 + 2 + 3 + 4 + 5 = 15 операций против 5^2 = 25 операций