Microsoft SQL Server 2008 - 99% фрагментация по некластеризованному, не уникальному индексу

У меня есть таблица с несколькими индексами (определено ниже). Один из индексов (IX_external_guid_3) имеет фрагментацию 99% независимо от перестройки/реорганизации индекса. Кто-нибудь знает, что может вызвать это или лучший способ исправить это?

мы используем Entity Framework 4.0 для запроса этого, запросы EF на другие индексированные поля примерно в 10 раз быстрее в среднем, чем поле external_guid_3, однако ADO.Net запрос примерно одинаковой скорости на обоих (хотя 2x медленнее, чем запрос EF к индексированным полям).

таблица

  • id (PK, int, not null)
  • guid (uniqueidentifier, null, rowguid)
  • external_guid_1 (uniqueidentifier, не null)
  • external_guid_2 (uniqueidentifier, null)
  • состояние (varchar (32), null)
  • значение (varchar (max), null)
  • infoset (XML (.), null) -- > обычно 2-4K
  • created_time(datetime, null)
  • updated_time (datetime, null)
  • external_guid_3(uniqueidentifier, не null)
  • FK_id (FK, int, null)
  • locking_guid (uniqueidentifer, null)
  • locked_time (datetime, null)
  • external_guid_4(uniqueidentifier, null)
  • corrected_time (datetime, null)
  • is_add (бит, не null) оценка (int, null)
  • row_version(метки, null)

индексы

  • PK_table(Кластерных)
  • IX_created_time (Не Уникальный, Не Кластеризованный)
  • IX_external_guid_1 (Не Уникальный, Не Кластеризованный)
  • IX_guid (Не Уникальный, Не Кластеризованный)
  • IX_external_guid_3 (Не Уникальный, Не Кластеризованный)
  • IX_state (Не Уникальный, Некластеризованный)
6
entity-framework-4 sql-server

4 ответов

Примечание: рекомендации SQL Server утверждают, что индексы с менее чем 10 000 страниц обычно не выигрывают от повышения производительности.

см.http://technet.microsoft.com/en-gb/library/cc966523.aspx http://technet.microsoft.com/en-us/magazine/2008.08.database.aspx?pr=blog

вот небольшой фрагмент, чтобы определить, когда ваша БД нуждается в дефрагментации.В нашем продукте мы сократили это до 2000 и выбрали фрагментацию >20%. Вы можете легко изменить скрипт, чтобы рассказать вам, какие индексы, в частности.

SELECT COUNT(*) AS fragmented_indexes FROM sys.dm_db_index_physical_stats(DB_ID(), null, null, null, null) as p WHERE p.avg_fragment_size_in_pages <= 1 AND p.avg_fragmentation_in_percent >= 20 AND p.page_count > 2000;
3

на самом деле это выглядит просто как индексация на guid может быть виновником здесь: http://www.sqlskills.com/blogs/paul/can-guid-cluster-keys-cause-non-clustered-index-fragmentation/

в последнее время я нахожу несколько ссылок, которые, похоже, поддерживают это.

3

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

пока количество страниц индекса не достигнет 100 или около того, фрагментация не повлияет на производительность.

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

запустите запрос из среды management studio (вы можете запрос с помощью SQL profiler или монитора активности, если он динамический) и нажмите "Включить фактический план выполнения". Это покажет вам, какой индекс используется, и если запрос покрыт.

0

Turn db auto shrink off. Кажется, это имеет побочный эффект фрагментации индексов.

0