SQL Server: плотность сканирования индекса 12% и фрагментация 50%.Насколько плохо "плохо"?

Question

Насколько фрагментация плоха?Насколько низкая плотность сканирования слишком низкая?Насколько низкая плотность сканирования плохо ?

У меня есть таблица со следующими показателями плотности индекса и уровнями фрагментации:

Name                           Scan Density  Logical Fragmentation
=============================  ============  =====================
IX_TransactionEntries_Tran...  12.834        48.392
IX_TransactionEntries_Curr...  15.419        41.239
IX_TransactionEntries_Tran...  12.875        48.372
TransactionEntries17           98.081         0.0049325
TransactionEntries5            12.960        48.180
PK_TransactionEntries          12.869        48.376
TransactionEntries18           12.886        48.480
IX_TranasctionEntries_CDR...   12.799        49.157
IX_TransactionEntries_CDR...   12.969        48.103
IX_TransactionEntries_Tra...   13.181        47.127

Вы можете видеть, что я просто дефрагментируется TransactionEntries17, поэтому его Плотность сканирования настолько высока, а фрагментация настолько низка.

Но составляет 12% плотности сканирования ужасно низко?Является ли 48% фрагментация ужасной высокой?

У меня возникают проблемы с производительностью при удалении строк (что требует сканирования индекса).Является ли фрагментация индекса GIANT FLASHING RED ALARM для индекса страницы 70000 или возможна , но маловероятна причина?

---

Из SQL Server BOL:

Плотность сканирования [Наилучший счет: Фактический счет]

В процентах.Это соотношение Best Count к Actual Count .Это значение равно 100, если все смежно;если это значение меньше 100, существует некоторая фрагментация.

Наилучший счет - это идеальное число изменений экстента, если все непрерывно связано. Actual Count - фактическое количество изменений экстента.

LogicalFragmentation

Процент страниц, вышедших из строя при возврате при сканировании конечных страниц индекса.Этот номер не имеет отношения к кучам.Страница, вышедшая из строя, - это страница, для которой следующая физическая страница, выделенная для индекса, не является страницей, на которую указывает указатель следующей страницы на текущей конечной странице.

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

Answer 1

Как и все остальное в SQL, это зависит .

Это будет зависеть от таких вещей, как конфликт (который увеличивает время ожидания, так как есть больше страниц данных, за которые "приходится бороться"), какШирокие ваши индексы, и т. д. и т. д. и т. п.

Исходя из моего личного опыта, я провел некоторое тестирование воздействия фрагментации на некоторые сборки и нагрузки, которые я запускаю.Я запустил один прогон для таблицы, которая была фрагментирована на 40%, а другой - для «той же» таблицы с фрагментацией 0%.

Для фрагментированной таблицы на 40% потребовалось 1200% больше те же основные операции.

Ваш пробег может отличаться, но это имеет большое значение.

Пол Рэндал, возможно, ответственный за большую часть DBCC в SQL Server 2005+, считает, что этоЭто тоже довольно большое дело.

Короче говоря, единственный способ узнать наверняка - это провести тестирование.BOL не дает рекомендаций по диапазонам плотности и фрагментации, потому что слишком много переменных, чтобы сделать «общую» оценку.

Это все равно что спросить "Не слишком ли повреждена моя машина?"Ответ зависит от того, «слишком поврежден для чего?», Как далеко вы едете, как быстро, на каких дорогах, в какую погоду, в какое время года и на миллион других вещей.