Является ли высокая степень фрагментации проблемой?

DBCC SHOWCONTIG scanning 'MyTable' table...
Table: 'MyTable' (2048062382); index ID: 1, database ID: 28
TABLE level scan performed.
- Pages Scanned................................: 1019182
- Extents Scanned..............................: 127400
- Extent Switches..............................: 127399
- Avg. Pages per Extent........................: 8.0
- Scan Density [Best Count:Actual Count].......: 100.00% [127398:127400]
- Logical Scan Fragmentation ..................: 0.01%
- Extent Scan Fragmentation ...................: 77.25%
- Avg. Bytes Free per Page.....................: 135.7
- Avg. Page Density (full).....................: 98.32%

Я читал, что Scan Density = 100% очень хорош, и логическое сканирование Fragementation <1% также отлично. 77% Экстенсиональное сканирование Фрагментация меня беспокоит, но интернет говорит, чтобы игнорировать ее.

Я анализирую медленный исполняемый запрос с одной таблицей. Он запускает ~ 30 секунд при первом выполнении, затем 200 мс во втором и последующих исполнениях. Я могу сбросить это поведение с помощью DBCC DROPCLEANBUFFERS.

Является ли высокая расширенная проверка фрагмента важной подсказкой?

(Если нет, я, скорее всего, добавлю еще один вопрос о моем однострочном запросе).

6 голосов | спросил Amy B 16 PMpTue, 16 Apr 2013 20:24:04 +040024Tuesday 2013, 20:24:04

1 ответ


4
  

ConstantScan-> NestedLoop-> IndexSeek-> NestedLoop-> План KeyLookup

Этот план не имел доступа ко всей таблице, так как он возвращал только 7000 строк из 34.5M строк.

Общий объем данных, поступающих с диска, является минимальным по сравнению с размером всей таблицы 1 ; случайное время поиска для выполнения ключевых операций поиска, по-видимому, доминирует. Фиксирование проблем фрагментации применяется только при выполнении операций scan . Как только шаблон доступа случайный, как представляется, здесь, фрагментация - и фрагментация - не имеют значения.

Вы должны быть в состоянии проверить, что происходит, наблюдая активность диска в мониторе производительности или мониторе ресурсов во время выполнения запроса - я ожидаю, что вы увидите очень низкую пропускную способность диска.

Предполагая, что мой анализ верен, вот несколько предложений (которые можно объединить), чтобы улучшить время выполнения запроса, особенно с холодным кешем:

  • Поместите файлы данных в подсистему хранения, которые могут лучше обрабатывать случайные чтения. Как приблизительная оценка, 30 секунд /7000 строк - это среднее время поиска ~ 4 мс, что неплохо, поэтому это может быть дорогостоящим предложением.

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

1 Предполагая приблизительно равные размеры строк.


Кроме того, в качестве стороннего, DBCC SHOWCONTIG долгое время устарел - замена будет следующей: sys.dm_db_index_physical_stats .

ответил Jon Seigel 17 AMpWed, 17 Apr 2013 08:21:21 +040021Wednesday 2013, 08:21:21

Похожие вопросы

Популярные теги

security × 330linux × 316macos × 2827 × 268performance × 244command-line × 241sql-server × 235joomla-3.x × 222java × 189c++ × 186windows × 180cisco × 168bash × 158c# × 142gmail × 139arduino-uno × 139javascript × 134ssh × 133seo × 132mysql × 132