Системы с высокой параллельностью на бумаге всегда выглядят впечатляюще. Вы добавляете десятки процессорных ядер, увеличиваете объём памяти, проектируете схему с «лёгкими» вставками и с удовлетворением думаете: «Всё полетит». И, по правде говоря, при небольшой нагрузке так и выходит. Одна сессия, вставляющая строки в простую таблицу, даже не заставляет SQL Server напрячься.
Но картина меняется, как только вы начинаете нагружать систему сотнями параллельных вставок. Внезапно вся вычислительная мощь перестаёт иметь значение, потому что каждый поток бьётся за одно крошечное место в памяти: последнюю страницу кластерного индекса. Это классическая проблема «last-page insert contention problem». Она возникает всякий раз, когда ключ кластерного индекса последовательный — типичные IDENTITY, DATETIME или NEWSEQUENTIALID(). Каждая новая строка естественным образом «тянется» в конец B-дерева. Это звучит упорядоченно и эффективно, но при конкуренции — это ловушка. Вместо распределения вставок по нескольким страницам все они наваливаются на одну «горячую» страницу.
