должны ли почти уникальные поля иметь индексы

Question

У меня есть поле в базе данных, которое почти уникально:в 98% случаев значения будут уникальными, но они могут содержать несколько дубликатов.Я не буду проводить много поисков в этой области;скажем, два раза в месяц.В настоящее время таблица содержит ~ 5000 записей и будет набирать около 150 в месяц.

Должно ли это поле иметь индекс?

Я использую MySQL.

Answer 1

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

Ответ:

5000 записей - это совсем немного, и независимо от того, есть ли у вас индекс, поиск все равно будет быстрым. При такой скорости вставок вам понадобится 3 года, чтобы получить 10000 записей, что также не так много.
Лично я не стал бы добавлять индекс, но это не имело бы значения.

Объяснение:

При принятии решения о добавлении индекса необходимо учитывать компромисс между скоростью вставки и скоростью выбора.

Без индекса выполнение select в этом поле означает, что MySQL должен пройтись по каждой строке и прочитать каждое поле. Добавление индекса предотвращает это.

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

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

Answer 2

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

Answer 3

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

Answer 4

Из того, что вы говорите, не похоже, что указатель необходим. Основное правило - индексные поля, которые используются в SELECTS для ускорения поиска, что в свою очередь (может) замедляет вставки и обновления.

На таком маленьком альбоме, как ваш, я не думаю, что вы увидите большую часть реального мира в любом случае.

Answer 5

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

Answer 6

Нет.Записей не так много, и к ним не будут часто обращаться.Нет необходимости индексировать.

Answer 7

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

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

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

РЕДАКТИРОВАТЬ: Что касается изменения требований, то нужно учитывать следующее: если БД действительно растет, и позже вы обнаружите, что вам нужен индекс, можете ли вы просто создать индекс и все готово? Или вам также потребуется изменить большое количество кода, чтобы использовать новый индекс?

Answer 8

Это зависит. Как ответили другие, существует компромисс между скоростью обновления таблицы и скоростью выбора. Обновление таблицы включает вставки, обновления и удаления в таблице.

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

Если в таблице нет кандидатов на первичный ключ, это обычно указывает на серьезный недостаток в оформлении таблицы. Это отдельная проблема, и ее следует обсудить отдельно.