SQL Server 2005: индекс больше, чем хранимые данные

Question

Я создал 1 базу данных с 2 группами файлов: 1 основной и 1 индекс.

• Основная группа файлов включает 1 файл данных (* .mdf): сохраняются все таблицы
• ИндексВ группу файлов входит 1 индексный файл (* .ndf): хранить все индексы

Большинство индексов являются некластеризованными индексами

После непродолжительного использования базы данных файл данных2 ГБ, но индексный файл составляет 12 ГБ.Я не знаю, какая проблема произошла в моей базе данных.

У меня есть несколько вопросов:

1. Как уменьшить размер файла индекса?
2. Как сделатьЯ знаю, что хранится в файле индекса?
3. Как отследить все воздействия на файл индекса?
4. Как ограничить увеличение размера файла индекса?

Answer 1

Как уменьшить размер индексного файла?

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

Если у вас есть индекс на a,b,c,d и индекс на a,b,c, вы можете отказаться от второго, поскольку первый покрывает второй.

Вы также можете найти потенциальные неиспользуемые индексы , посмотрев на sys.dm_db_index_usage_stats

Как узнать, что хранится в индексном файле?

Он будет хранить все, что вы определили, чтобы хранить! Следующий запрос поможет вам определить, какие индексы используют больше места и по какой причине (в данных строки, данных lob)

SELECT  convert(char(8),object_name(i.object_id)) AS table_name, i.name AS index_name, 
    i.index_id, i.type_desc as index_type,
    partition_id, partition_number AS pnum,  rows, 
    allocation_unit_id AS au_id, a.type_desc as page_type_desc, total_pages AS pages
FROM sys.indexes i JOIN sys.partitions p  
      ON i.object_id = p.object_id AND i.index_id = p.index_id
    JOIN sys.allocation_units a
      ON p.partition_id = a.container_id
      order by pages desc

Answer 2

Учтите, что на самом деле вполне достаточно, чтобы общее хранилище, необходимое для индексов, было больше, чем хранилище, необходимое для данных таблицы в данной базе данных.

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

Предоставление подробной информации о вашей схеме таблицы и структурах индекса позволит нам предоставить вам более конкретные указания.

Другие авторы упоминали, что:

• Вам следует проверить определения индекса на наличие дублирующих индексов.Взгляните на Идентификация перекрывающихся индексов по Брент Озар .
• Вам следует поискать неиспользуемые индексы.Взгляните на статью о SQL Server Pedia: Поиск неиспользуемых индексов

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

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

См. Реорганизация и перестройка индексов

Answer 3

Мое предположение (которое, я думаю, куда и возглавляет marc_s) состоит в том, что вы объявили свои кластеризованные индексы, чтобы хотя бы некоторые из ваших таблиц были в группе файлов индекса. Кластерный индекс определяет, как (и где) хранятся фактические данные для вашей таблицы.

Размещение некоторого вашего кода, безусловно, поможет другим точно определить проблему.

Я думаю, что Мартин Смит довольно хорошо ответил на ваши другие вопросы. Я просто добавлю это ... Если вы хотите ограничить размеры индекса, вам нужно оценить ваши индексы. Не добавляйте индексы только потому, что думаете, что они могут вам понадобиться. Проведите тестирование с реалистичными (или в идеальном случае реальными) нагрузками на базу данных, чтобы увидеть, какие индексы действительно дадут вам необходимое повышение производительности. Индексы имеют затраты для них. В дополнение к стоимости места, которую вы видите, они также увеличивают накладные расходы на вставки и обновления, которые должны синхронизировать индексы. Из-за этих затрат у вас всегда должна быть веская причина для добавления индекса, и вы должны сознательно подумать о компромиссах.

Answer 4

@ Ответ Мартина-Смита - почти то, что мне нужно ...

Вот как вы сортируете по размеру индекса в ГБ (mssql использует 8 КБ страниц == 128 страниц / МБ)

SELECT
  object_name(p.object_id) AS table_name
  , i.name AS index_name
  , i.index_id
  , i.type_desc AS index_type
  -- , partition_id
  -- , partition_number AS pnum
  -- , allocation_unit_id AS au_id
  , rows
  , a.type_desc as page_type_desc
  , total_pages/(1024 * 128.0) AS sizeGB
FROM 
    sys.indexes i
    JOIN sys.partitions p  ON i.object_id = p.object_id AND i.index_id = p.index_id
    JOIN sys.allocation_units a ON p.partition_id = a.container_id
    JOIN sys.all_objects ao ON (ao.object_id = i.object_id)
    WHERE ao.type_desc = 'USER_TABLE'
ORDER BY
    -- table_name 
    sizeGB DESC