Избегайте создания кластерного индекс, основанный на увеличивающемся ключе

Я получил этот совет от mssqlcity.com . Однако я не могу понять его объяснение.

Избегайте создания кластеризованного индекса на основе увеличивающегося ключа

Например, если таблица имеет суррогат целочисленный первичный ключ, объявленный как IDENTITY и кластерный индекс был создается в этом столбце, то каждые данные о времени вставляются в эту таблицу, строки будут добавлены в конец Таблица. Когда будет много строк добавлена ​​"горячая точка". Горячая пятно "возникает, когда многие запросы пытаются читать или писать данные в той же области на в то же время. "Горячая точка" приводит к Узкое место ввода-вывода. Запись. По умолчанию SQL Сервер создает кластерный индекс для ограничение первичного ключа. Итак, в этом случае вы должны явно указать Ключевое слово NONCLUSTERED, чтобы указать, что некластеризованный индекс создается для ограничение первичного ключа.

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

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

Я действительно не понимаю причину узкого места ввода-вывода, о котором они говорят. Они говорят, что слишком много операций, использующих одну и ту же страницу, замедлит работу с диском? Как это произошло? Может кто-нибудь объяснить мне?