Является ли это плохой стратегией индексации для таблицы?

Question

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

Metadata 
ResultID (PK, int, not null) 
MappedFieldname (char(50), not null) 
Fieldname (PK, char(50), not null) 
Fieldvalue (text, null) 

Сгруппированный индекс по ResultID и имени поля. Эта таблица обычно содержит миллионы строк (в одном случае она содержит 500 миллионов). Таблица заполняется 24 рабочими, работающими по 4 потока каждый, когда данные «обрабатываются». Это приводит к множеству непоследовательных вставок. Позже после обработки в эту таблицу добавляется больше данных с помощью нашего собственного программного обеспечения. Фрагментация для данной таблицы составляет не менее 50%. В случае с самой большой таблицей она составляет 90%. У нас нет DBA. Я знаю, что нам отчаянно нужна стратегия обслуживания БД. Насколько мне известно, я студент колледжа, работающий неполный рабочий день в этой компании.

Мой вопрос в том, является ли кластеризованный индекс лучшим способом для этого? Следует ли учитывать другой индекс? Есть ли хорошие ссылки для этого типа и аналогичные специальные задачи DBA?

Answer 1

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

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

Если вы не абсолютно, необходимо иметь кластеризованный индекс, охватывающий два поля, а затем нет. Если это больше похоже на некоторое УНИКАЛЬНОЕ ограничение, то, во всяком случае, сделать его УНИКАЛЬНЫМ ограничением. Для них не требуется повторная сортировка.

Определите, каков типичный запрос к таблице, и соответственно разместите индексы. Чем больше индексов у вас, тем медленнее будут изменения данных (INSERT/UPDATE/DELETE). Не создавайте слишком много индексов, например. на поля, которые вряд ли будут отфильтрованы/отсортированы.

Создайте комбинированные индексы только для полей, которые отфильтровываются/сортируются по вместе, как правило.

Answer 2

Сгруппированный индекс в порядке, насколько я вижу. Что касается других индексов, вам нужно будет предоставить типичные SQL-запросы, которые работают в этой таблице. Просто создание индекса из голубого не является хорошей идеей. Вы говорите о фрагментации и индексировании, означает ли это, что вы подозреваете, что выполнение запросов замедляется? Или вы просто хотите сжать/дефрагментировать базу данных/индекс?

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

Answer 3

Посмотрите на свои запросы - те, которые попадают в таблицу для данных. Будет ли индекс служить? Если у вас есть индекс (ResultID, FieldName) в этом порядке, но вы запрашиваете возможные значения ResultID для заданного имени поля, вероятно, что СУБД будет игнорировать индекс. Напротив, если у вас есть индекс (FieldName, ResultID), он, вероятно, будет использовать индекс - конечно, для простого поиска значений (WHERE FieldName = 'abc'). С точки зрения уникальности, либо индекс работает хорошо; с точки зрения оптимизации запросов, существует (по крайней мере потенциально) огромная разница.

Используйте EXPLAIN, чтобы узнать, как ваши запросы обрабатываются вашей СУБД.

Clustered vs non-clustered indexing обычно является эффектом оптимизации второго порядка в СУБД. Если у вас есть правильный указатель, существует небольшая разница между кластерным и некластеризованным индексом (с большим штрафом за обновление для кластерного индекса в качестве компенсации за несколько меньшее время выбора). Убедитесь, что все остальное оптимизировано, прежде чем беспокоиться о эффектах второго порядка.

Answer 4

Я знаю, что нам отчаянно нужна стратегия обслуживания БД.

+1 для определения этой потребности

Насколько мой фон, я студент колледжа работает неполный рабочий день в этой компании

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

Таблица заполняется 24 работников, работающих под управлением 4 нити каждый

Я полагаю, что это довольно критически важным в течение рабочего дня, а также время простоя плохие новости? Если так, не кладите с ним.

Существует кластерный индекс ResultID и FIELDNAME

ли ResultID первый столбец в ПК, как вы указать?

Если да, то я буду держать пари, что он недостаточно избирателен и, в зависимости от потребностей запросов, порядок полей PK должен быть заменен (несмотря на то, что этот сложный ключ выглядит плохим выбором для кластерный PK)

Что результат:

SELECT COUNT (*), COUNT (DISTINCT ResultID) FROM MyTable

Если первый отсчет, скажем, 4 х, как большой, как второй, или более того, вы, скорее всего, будете получать отсканированные изображения, предпочитая поиск, из-за низкого выборочного результата ResultsID, и некоторые простые изменения будут дают огромные улучшения производительности.

Кроме того, поле Name довольно широко (50 символов), поэтому любые вторичные индексы будут иметь 50 + 4 байта, добавленные к каждой записи индекса. Действительно ли поля действительно CHAR, а не VARCHAR?

Лично я хотел бы рассмотреть увеличение плотности листовых страниц. При 90% вы оставите лишь несколько пробелов - может быть, один за страницу. Но с большой таблицей в 500 миллионов строк более высокая плотность упаковки может означать меньшее количество уровней в дереве и, следовательно, меньшее количество поисков. Против этого почти каждая вставка для данной страницы потребует разбиения страницы. Это будет способствовать вставкам, которые кластеризованы, поэтому может быть нецелесообразным (учитывая, что ваши данные вставки, вероятно, не кластеризованы). Как и многие вещи, вам нужно будет провести тест, чтобы определить, какая плотность индексных клавиш работает лучше всего.SQL Server имеет инструменты, помогающие анализировать, как обрабатываются запросы, кэшируются ли они, сколько сканирует их таблицу, какие запросы «медленны» и т. Д.

Получить консультанта, чтобы взглянуть и дать вам несколько советов. Это вопрос, который дает ответы на эти вопросы, чтобы дать вам безопасное решение для реализации.

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

Таблица нуждается в дефрагментации (ваши варианты станут меньше, если у вас нет кластерного индекса, так что держите это, пока не решите, что есть лучший кандидат). Методы дефрагментации «Online» будут иметь скромное влияние на производительность и могут отключаться - и могут быть безопасно прерваны, если они превысят время/ограничения ЦП [хотя это, скорее всего, займет некоторое программирование]. Если у вас есть «тихий» слот, используйте его для дефрагментации таблицы и обновления статистики по индексам. Не ждите, пока выходные не попытаются сделать все столы за один раз - сделайте столько/много, сколько сможете, в любое спокойное время каждый день (в течение ночи, предположительно).

Дефрагментация таблиц может привести к значительному увеличению использования журнала транзакций, поэтому убедитесь, что все TLogs были скопированы часто (у нас есть 10-минутная политика резервного копирования TLog, которую мы увеличиваем с каждой минутой во время дефрагментации таблицы, так что что процесс дефрагментации не станет определением требуемого пространства Tlog!)