Быстрое фрагментирование индекса в SQL Server

У меня есть запрос, который в настоящее время работает на двух физических серверах просто отлично в около 7 секунд. Запрос является относительно сложным, поскольку он объединяет несколько таблиц и формируется Entity Framework. В настоящее время я переношу базу данных в практически размещенную среду, и все, кажется, в порядке, за исключением этого одного запроса. При запросе к фактически размещенному экземпляру SQL Server запрос сначала выполняется за 7 секунд, но через час или два внезапно займет около 8 протокол.

глядя на план выполнения в то время как в медленном состоянии я определил неожиданное полное сканирование таблицы. Если я перестрою индекс на этой таблице, он мгновенно вернется к 7 секундам. Однако в течение часа или около того он переключится на 8 минут.

таблица в вопросе имеет очень мало изменений, и часто я был в состоянии определить нулевое изменение между ним работает хорошо и работает медленно. После восстановления индекса фрагментация падает примерно до 0,02%, но в течение часа или двух он прыгает между 50%-60%.

  • наполненность страницы – 52.95%
  • общая фрагментация – 54.19%
  • средний размер строки – 338
  • глубина – 3
  • переадресованные записи-0
  • Ghost records-0
  • тип индекса-кластеризованный индекс
  • строки уровня листа-134900
  • максимальный размер строки – 604
  • минимальный размер строки – 239
  • страницы – 10736
  • ID раздела – 1
  • версия ghost rows-0

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

6
sql sql-server sql-server-2008

2 ответов

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

  • фактор заполнения также может повлиять на фрагментацию.

  • статистика по этой таблице может не обновляться

  • вы можете быть жертвой проблемы обнюхивания параметров (план запроса кэшируется, но не самый оптимальный). Можете ли вы проверить, если один и тот же запрос план используется для обоих случаев?

  • - вы уверены, что оба запроса идентичны? Если нет, то какая разница?

мы могли бы помочь вам больше, если вы поместите экран печати с информацией о фрагментации из sys.dm_db_index_physical_stats когда запрос работает хорошо, соответственно плохо.

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

у Вас очень мало изменений, но наверняка количество страниц удваивается, поэтому я подозреваю, что "небольшое обновление", которое сделано на всех (или почти всех) строках в таблице из-за этой 53% внутренней фрагментации.

другие действия, которые необходимо выполнить:

  • 1 / будет полезно опубликовать структуру таблицы, чтобы посмотреть.
  • 2 / у вас есть столбец с типом данных CHAR?
  • 3/ список среднее количество строк на странице (быстрый и медленный)
  • 4 / Проверьте все хранимые процедуры / запросы, которые касаются этой таблицы
  • 5 / добавить триггер и журнал (в другой таблице?) действия, выполняемые на вашем столе (у вас может быть UPDATE TableX SET colA = colA WHERE 1=1)

держит нас в курсе.

2

насколько я знаю, фрагментация индекса также может привести к снижению производительности. Это может произойти из-за DML для этой таблицы.

вы видите, что заполненность страницы составляет около 52%. у вас есть 10736 страниц с кластеризованным индексом, представьте, что при выполнении запроса select с полным сканированием индекса он будет перемещаться по страницам, пока не получит запись соответствия. Это будет стоить вам производительности.

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

может, то, что вы можете сделать, это:

  1. проверить, какие индексы у вас есть в этой таблице.
  2. какой запрос коснитесь таблицы

ожидание обратной связи от вас..

0