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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

итак, вкратце:

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

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