Должны ли поля даты с возможностью поиска в таблице базы данных всегда индексироваться?

Question

Если у меня есть поле в таблице какого-либо типа даты, и я знаю, что я всегда буду искать его, используя сравнения, такие как between, > или <, и никогда = не может быть хорошей причиной не добавить индекс для него?

Answer 1

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

Это может произойти, если:

• У вас действительно тяжелый DML на вашем столе
• Наличие индекса делает его невыносимо медленным, а
• Гораздо быстрее иметь DML, чем быстрые запросы.

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

Answer 2

Есть гораздо более плохие причины.

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

Answer 3

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

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

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

• Если у вас не может быть много покрытых индексов (данные сильно изменяются в таблице, имеется ограниченное пространство, ваши результирующие наборы большие и разнообразные), и / или вам действительно нужен кластеризованный индекс для другого столбец, а типичные критерии даты дают широкий диапазон записей, и вам приходится много искать, у вас есть проблемы. Если вы можете записать данные в таблицу отчетов, сделайте это. Если вы не можете, то вам придется тщательно сбалансировать все эти конкурирующие факторы. Возможно, для первых 2-3 поисков вы минимизируете столбцы набора результатов настолько, насколько можете настроить покрытые индексы, а остальные позволяют сделать это с помощью простого некластеризованного индекса

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

Answer 4

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

Answer 5

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

Answer 6

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

Answer 7

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

Существуют типы данных (например, изображения в SQL Server) и распределения данных, где индексы вряд ли будут использоваться или не могут быть использованы. Например, в SQL Server индексировать битовое поле бессмысленно, так как в данных недостаточно изменчивости для индекса, чтобы он приносил какую-либо пользу.

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