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

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

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

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 % ужасно высокой?

я получаю проблемы с производительностью при удалении строк ( который требует сканирования индекса). Является ли фрагментация индекса ГИГАНТСКОЙ МИГАЮЩЕЙ КРАСНОЙ СИГНАЛИЗАЦИЕЙ на 70000-страничном индексе или возможная, но маловероятная причина?

Из SQL Server BOL:

Плотность сканирования [Лучший подсчет: фактический подсчет]

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

Best Count – это идеальное количество изменений экстента, если все последовательно связано. Фактическое количество — это фактическое количество изменений экстента.

Логическая фрагментация

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

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


sql-server indexing sql-server-performance sql-server-2000 fragmentation
person Ian Boyd    schedule 05.10.2011    source источник

Ответы (1)


arrow_upward
3
arrow_downward

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

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

Исходя из своего личного опыта, я провел некоторое тестирование влияния фрагментации на некоторые сборки и нагрузки, которые я запускаю.

Для процедуры с интенсивным агрегированием я выполнил один запуск для таблицы с фрагментацией на 40%, а другой — для «той же» таблицы с фрагментацией на 0%.

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

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

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

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

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

person JNK    schedule 05.10.2011
comment
Что, если бы это были мои шины, накачанные только на 50%. Для меня это было бы нужно исправить этот момент. - person Ian Boyd; 05.10.2011
comment
@IanBoyd - если вы не едете со скоростью 5 миль в час по песчаным дюнам, в этом случае могут подойти спущенные шины ... - person JNK; 05.10.2011
comment
я двигаюсь со скоростью 382 мили в час (382 строки в час = 7 строк в секунду). - person Ian Boyd; 06.10.2011
comment
@IanBoyd - вам все еще нужно протестировать :) Готов поспорить, вы увидите значительное улучшение, перестроив индексы. - person JNK; 06.10.2011
comment
Что я хотел бы сделать. Но после того, как мы запланировали время простоя и пригласили государственных аудиторов, чтобы контролировать время простоя, и это не исправило ситуацию... - person Ian Boyd; 06.10.2011