База данных индексов: только выбирает!

Question

Добрый день,

У меня около 4 ГБ данных, разделенных примерно на 10 разных таблиц. В каждой таблице много столбцов, и каждый столбец может быть критерием поиска в запросе. Я совсем не администратор баз данных, и я не очень разбираюсь в индексах, но я хочу максимально ускорить поиск. Важным моментом является то, что в любой момент не будет обновлений, вставок или удалений (таблицы заполняются раз в 4 месяца). Уместно ли создавать индекс для каждого столбца? Помните: не вставлять, обновлять или удалять, только выбирает! Кроме того, если бы я мог сделать все эти столбцы целочисленными вместо varchar, я бы сделал разницу в скорости?

Большое спасибо!

Answer 1

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

Мастер настройки, упомянутый в других ответах, является хорошим первым вариантом (особенно для ученика).

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

Answer 2

Рассматривали ли вы запуск мастера настройки индексов ? Предоставит вам рекомендации по индексам на основе рабочей нагрузки.

Answer 3

Абсолютно нет.

Вы должны понимать, как работают индексы. Если у вас есть, скажем, 1000 записей, но это BIT, и может быть одно из двух значений, если вы индексируете только этот столбец и этот столбец, это будет бесполезным, поскольку оно не будет достаточно избирательным. Когда вы индексируете по столбцу, очень хорошо знаете, какие типы выбора будут выполняться в таблице. Когда вы создаете индекс по столбцу, будет ли этот индекс достаточно избирательным для эффективного использования оптимизатором?

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

Answer 4

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

В противном случае это компромисс: каждый индекс будет добавлять примерно столько же места, что и имя из одного столбца, содержащего те же данные, так что вы существенно удвоите (вероятно, в 2,5 раза) ваши требования к пространству. Так что, возможно, 10G, что не так много данных.

Тогда возникает вопрос, будет ли ваша СУБД эффективно объединять несколько выборок на основе индекса. Вполне возможно, что этого не произойдет, если вы не выполните самостоятельные объединения для каждого столбца, против которого вы выбираете.

Лучший ответ: попробуйте его на меньшем наборе данных (чтобы не тратить все свое время на построение индексов) и посмотрите, как он работает.

Answer 5

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

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

Это означает, что вы получаете выгоду только за свой доллар с индексом NC любого вида, если индекс покрывает или выбирает достаточно малый набор данных, который снижает стоимость поиска по закладке - действительно, вы можете обнаружить, что Оптимизатор запросов даже не будет смотреть на ваши индексы, если цена будет непомерно высокой по сравнению со сканированием кластерного индекса, где все столбцы уже доступны.

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

итого в итоге:

1) Не индексируйте каждый столбец. Это классическая преждевременная оптимизация. Вы не можете заранее оптимизировать большую таблицу с индексами для всех возможных планов запросов.

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