Если у меня есть поле в таблице некоторого типа даты, и я знаю, что я всегда буду искать его с помощью сравнений, как between, > или < и никогда = мог быть веской причиной не добавить индекс для этого ?Должны ли индексироваться поля с возможностью поиска в таблице базы данных?
Единственная причина не добавлять индекс в поле, которое вы собираетесь искать, это то, что стоимость поддержания индекса перевешивает его преимущества.
Это может произойти, если:
DML на вашем столеDML, чем быстрые запросы.Если это не так, то просто создайте индекс. Оптимизатор просто не будет использовать его, если он считает, что он не нужен.
Не индексируйте его, если вы хотите сканировать всю таблицу каждый раз. Я хотел бы, чтобы база данных пыталась выполнить сканирование диапазона, , поэтому я бы добавил индекс, но я использую SQL Server, и он будет использовать этот индекс в большинстве случаев. Однако разные базы данных не используют индекс.
Не могли бы вы объяснить, почему я хотел бы сканировать всю таблицу каждый раз? Вы имеете в виду, если у меня есть другие параметры, которые уже требуют сканирования типа «Active = 1»? –
возьмите телефонную книгу и выполните сканирование диапазона на «Jones», теперь притворитесь, что телефонная книга находится в случайном порядке и выполняет полное сканирование таблицы (обложка для обложки), ища все имена «Jones». Что будет быстрее? –
Дальность сканирования конечно. Я спрашиваю: «Не индексируйте его, если вы хотите каждый раз сканировать всю таблицу». есть ли какая-то причина, по которой я хотел бы сканировать всю таблицу каждый раз? –
В зависимости от данных, я бы пошел дальше этого и предположил, что это может быть кластеризованный индекс, если вы собираетесь делать BETWEEN запросов, чтобы избежать сканирования таблицы.
Есть гораздо более плохие причины.
Однако индекс в столбце поиска может быть недостаточным, если индекс некластеризован и non-covering. Подобные запросы часто являются хорошими кандидатами для кластеризованных индексов, однако индекс покрытия также хорош.
+1 для упоминания индексов покрытия - что-то слишком много людей по-прежнему игнорируют ... –
+1 от меня тоже. Раньше я не слышал об этой концепции. –
Хотя индекс помогает запросить таблицу, он также замедляет вставку, обновление и удаление. Если в таблице больше изменений, чем запросов, индекс может повредить общую производительность.
Это прекрасный пример того, почему это столько искусства, как наука. Некоторые соображения:
Как часто и применяются данные, добавленные в эту таблицу? Если есть далеко больше чтения/поиска, чем добавление/изменение (вся точка некоторых таблиц для передачи данных в отчет), то вы хотите сходить с ума по индексам. Вам может понадобиться кластеризованный индекс для поля ID, но у вас может быть много индексов с несколькими столбцами (где поля даты появляются позже, а столбцы, перечисленные ранее в индексе, делают хорошую работу по сокращению набора результатов) и охватывают индексы (где все возвращаемые значения находятся в индексе, так что это очень быстро, как вы начинаете с кластерного индекса).
Если таблица отредактирована или добавлена часто, или у вас ограниченное пространство для хранения и, следовательно, не может быть тонны индексов, тогда вам нужно быть более осторожным с вашими индексами. Если ваши критерии даты обычно предоставляют широкий диапазон данных, и вы не часто выполняете поиск в других полях, то вы можете получить , указав кластерный указатель на это поле даты, но подумайте несколько раз, прежде чем это сделать.Вы кластеризованный индекс, находящийся в простом поле автонабора, является бонусом для всех ваших индексов. Нераскрытые индексы используют кластеризованный индекс для записи в записи для набора результатов. Не перемещайте кластеризованный индекс в поле даты, если только огромным в основном поле поиска находится в этом поле даты. Это ядерный вариант.
Если у вас не так много покрытых индексов (данные сильно изменяются на столе, ограниченное пространство, ваши результирующие наборы большие и разнообразные) и/или вам действительно нужен кластеризованный индекс для другого столбца , а типичные критерии даты дают широкий диапазон записей, и вам приходится много искать, у вас проблемы. Если вы можете сбросить данные в таблицу отчетов, сделайте это. Если вы этого не сделаете, вам нужно будет сбалансировать все эти конкурирующие факторы. Может быть, для первых 2-3 поисков вы минимизировать результат посаженных столбцов столько, сколько вы можете настроить охватываемые индексы, и пусть остальные делают из-за простым, не -clustered индексом
Вы можете понять, почему хорошо db людям следует платить хорошо. Я знаю много факторов, но я завидую людям, чтобы они могли сбалансировать все эти вещи быстро и правильно, не занимаясь большим профилированием.
Если таблица небольшая, она может никогда не использовать индексы, поэтому их добавление может просто растрачивать ресурсы.
Существуют типы данных (например, изображение на SQL Server) и распределения данных, где индексы вряд ли будут использоваться или не могут использоваться. Например, в SQL Server бессмысленно индексировать битовое поле, поскольку в данных недостаточно вариации для индекса, который может принести пользу.
Если вы обычно запрашиваете с подобным предложением и подстановочным знаком в качестве первого символа, индекс не будет использоваться, поэтому создание одного из них - это еще одна трата ресурсов.
Немой вопрос. Что такое DML? –
Язык манипулирования данными (вставка, обновление, удаление, выбор) в отличие от DDL (Data Definition Language), например создание, падение и т. Д. – MJB
Ах спасибо. Раньше этого не видел. –