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

Но помните, что даже в tempdb производительность при использовании идентификатора и последовательности снижается по мерс уменьшения значения кэша. Поэтому, используя последовательность. необходимо указать большое значение кэша, такое как 10000. В случае с идентификатором следует избегать установки флага трассировки 272.

 Это верно вообще, не только в tempdb. Помните, что в любом случае ни идентификатор, ни последовательность не гарантируют отсутствия пробелов между значениями.

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

Например, если тип — INT, идентификатор использует значение кэша 1000; поэтому, чтобы получить аналогичную производительность при использовании последовательности, нужно большее значение, такое как 5000. В пользовательской базе данных следует избегать и с п ол ьзо ва н и я п осл е д о вател ь н ост и с NO CACHE или очень низкими значениями кэша, так как это приводит к низкой производительности из-за частых очисток журнала.

Информация, приведенная в этой статье, как уже говорилось, получена во время тестирования на моем компьютере с SQL Server 2014 RTM и SQL Server 2012 SP2. Компания Microsoft может изменить значения кэша по умолчанию без предупреждения, поэтому следует провести собственное тестирование, прежде чем принимать решение об оптимальном размере кэша для конкретной среды.