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

Question

У меня есть таблица с несколькими индексами (определено ниже).Один из индексов (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), ноль, rowguid)
• external_guid_1 (уникальный идентификатор, не ноль)
• external_guid_2 (уникальный идентификатор, ноль)
• состояние (varchar (32), ноль)
• value (varchar (max), null)
• infoset (XML (.), null) -> обычно 2-4K
• create_time (datetime, null)
• updated_time (datetime, null)
• external_guid_3 (уникальный идентификатор, не ноль)
• FK_id (FK, int, null)
• lock_guid (uniqueidentifer, null)
• locked_time (datetime, null)
• external_guid_4 (uniqueidentifier, null)
• corrected_time (datetime, null)
• is_add (бит, не ноль) счет (int, ноль)
• row_version (метка времени, ноль)

Индексы

• PK_table (Clustered)
• IX_created_time (неуникальный, некластеризованный)
• IX_external_guid_1 (неуникальный, некластеризованный)
• IX_guid (неуникальный,Некластеризованный)
• IX_external_guid_3 (неуникальный, некластеризованный)
• IX_state (неуникальный, некластеризованный)

Answer 1

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

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

Answer 2

Примечание. В рекомендациях по 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;

Answer 3

Отключить автоматическое сжатие дБ . Это похоже на побочный эффект фрагментации индексов.

Answer 4

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

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

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

Запустите запрос из студии управления (вы можете захватить запрос с помощью SQL Server Profiler или Activity Monitor, если он динамический) и нажмите «Включить фактический план выполнения». Это скажет вам, какой индекс используется и покрыт ли запрос.