Хорошо, вот несколько четких советов по созданию индекса: это зависит.
Это действительно ясно, но это не совсем точно. Если вы хотите что-то более конкретное, вам нужно узнать, от чего это зависит.
Это зависит от вашей СУБД и, возможно, даже от версии вашей СУБД. Вот несколько модных слов, о которых вы должны узнать, хотя бы поверхностно. Под «поверхностно» я имею в виду узнать, что это делает для вас и как это может вам навредить, но не обязательно, как это работает. Используйте документ, относящийся к вашей СУБД, если вы можете его получить.
Как избежать сканирования полной таблицы.
Индекс только поиск.
Дальность поиска. (и составные или составные индексы)
Объединение (обсуждается позже).
Хеш-индексы.
Контроль параллелизма (обсуждается позже).
Первичные ключи и индексы (обсуждаются позже).
Стоимость обновления индекса.
Отложенные обновления для индексов.
Оптимизация на основе затрат. Если в вашей СУБД нет CBO, получите другую СУБД.
Подсказки. (Как их использовать и как жить без них.)
Администрирование базы данных и CBO. Некоторые СУБД требуют периодических действий администратора баз данных, чтобы оптимизатор не использовал устаревшую стратегию.
Это зависит от объема: создание индекса относительно тривиально для очень маленьких таблиц. Под «относительно тривиальным» я подразумеваю, что это довольно просто, но это также неважно. Низкая стоимость ошибки. Если вы создаете таблицы поиска, вам наверняка понадобится уникальный индекс для столбца кода. Вы получите такую таблицу (с большинством СУБД), если объявите столбец кода в качестве первичного ключа. Если вы не создадите никаких других индексов, стоимость, вероятно, составит сканирование таблицы небольшой таблицы при необычных обстоятельствах, в которых допускается некоторая задержка.
Большие таблицы в любой схеме, как правило, являются теми, которые добавляются при обычной обработке транзакций. Это добавляет преимущества наличия некоторых индексов, как с точки зрения скорости, так и с точки зрения параллелизма транзакций. Это также увеличивает стоимость наличия индексов, потому что транзакции должны обновлять индексы. Соотношение затрат и выгод может быть очень тонким и очень важным для таблиц транзакций.
Если ваша СУБД поддерживает это, вы можете использовать отложенное обновление для получения хорошего эффекта с некоторыми индексами в таблицах транзакций.
В любой схеме хотя бы попытайтесь отличить справочные таблицы от таблиц транзакций. Я знаю, я знаю, это несколько субъективно. Используйте свое лучшее суждение.
Это зависит от трафика: не все таблицы получают одинаковое количество трафика. Индексы ускоряют как соединения, так и поиск. По крайней мере, вы должны узнать, есть ли в вашей СУБД оптимизатор, который знает, как выполнять объединения слиянием на основе доступных индексов и томов таблиц.
Если вы не знаете, что такое объединение слиянием, изучите, что это такое. Но не теряйте времени, изучая, как запрограммировать объединение, если вы не зарабатываете на жизнь таким образом.
Это зависит от срочности. Запрос, который выполняется один раз в месяц во время пакетной обработки beckground, не так срочен, как запрос, который задерживает пользователя 1000 раз в день, пока этот пользователь смотрит на экран, или контекст переключает его многозадачность.
Остерегайтесь того, что маркетинг продукта скажет вам о срочности. Они будут склонны говорить вам, что быть быстрее, чем участники соревнований, крайне необходимо в любых обстоятельствах, даже если это означает работу по вечерам и выходным, когда вы пропускаете рождение вашего первого ребенка. Маркетингу часто не важно, перегорели ли вы. Они как жокей, которому все равно, будет ли лошадь когда-нибудь снова участвовать в гонке. Правда заключается в том, что некоторые транзакции очень срочны, а другие относительно не важны.
Будьте готовы проявить гибкость при разработке индексов и учитывать компромиссы.
Хотел бы я указать вам действительно хорошую книгу на эту тему. Я надеюсь, что кто-то еще сделает это.