Если нужно где-то сохранить промежуточные данные и создать суррогатные ключи для строк, то везде, где только можно, задействуйте tempdb. Результаты при использовании как последовательности, так и идентификатора гораздо лучше в tempdb, чем в пользовательской базе данных. Нет операций внесения в журнал или очисток журнала, связанных с записью кэша на диск.
Но помните, что даже в tempdb производительность при использовании идентификатора и последовательности снижается по мерс уменьшения значения кэша. Поэтому, используя последовательность. необходимо указать большое значение кэша, такое как 10000. В случае с идентификатором следует избегать установки флага трассировки 272.
Это верно вообще, не только в tempdb. Помните, что в любом случае ни идентификатор, ни последовательность не гарантируют отсутствия пробелов между значениями.
Производительность при преобразовании из идентификатора в последовательность, следует компенсировать принудительные очистки журнала. Это означает, что для последовательности необходимо использовать значение кэша, которое превышает значение, применяемое идентификатором для такого же типа.
Например, если тип — INT, идентификатор использует значение кэша 1000; поэтому, чтобы получить аналогичную производительность при использовании последовательности, нужно большее значение, такое как 5000. В пользовательской базе данных следует избегать и с п ол ьзо ва н и я п осл е д о вател ь н ост и с NO CACHE или очень низкими значениями кэша, так как это приводит к низкой производительности из-за частых очисток журнала.
Информация, приведенная в этой статье, как уже говорилось, получена во время тестирования на моем компьютере с SQL Server 2014 RTM и SQL Server 2012 SP2. Компания Microsoft может изменить значения кэша по умолчанию без предупреждения, поэтому следует провести собственное тестирование, прежде чем принимать решение об оптимальном размере кэша для конкретной среды.
Комментарии