У меня есть поле в базе данных, которое почти уникально: в 98% случаев значения будут уникальными, но могут иметь несколько дубликатов. Я не буду много искать в этом поле; скажем два раза в месяц. В настоящее время в таблице около 5000 записей, и в месяц будет пополняться около 150 записей.
Должно ли это поле иметь индекс?
Я использую MySQL.
Я думаю, что «почти уникальный» — это отвлекающий маневр. Данные либо уникальны, либо нет, но это не определяет, хотите ли вы индексировать их из соображений производительности.
5000 записей действительно совсем немного, и независимо от того, есть ли у вас индекс, поиск все равно будет быстрым. При таком количестве вставок вам потребуется 3 года, чтобы получить 10 000 записей, что тоже немного.
Лично я не стал бы добавлять индекс, но это не имело бы значения, если бы вы это сделали.
При принятии решения о добавлении индекса вам следует подумать о компромиссе между скоростью вставки и скоростью выбора.
Без индекса выполнение select в этом поле означает, что MySQL должен пройти по каждой отдельной строке и прочитать каждое отдельное поле. Добавление индекса предотвращает это.
Недостатком индекса является то, что каждый раз, когда данные вставляются, БД должна обновлять индекс в дополнение к добавлению данных. Обычно это небольшие накладные расходы, но вы бы действительно заметили это, если бы у вас было множество индексов и вы выполняли много операций записи.
К тому времени, как вы получите столько строк в своей базе данных, вам все равно понадобится индекс, так как в противном случае ваш выбор займет весь день, но это просто то, о чем нужно знать, чтобы вы не добавили индексы к полям «просто». на случай, если мне это понадобится"
Это совсем не так много записей; Я бы не стал делать какие-либо индексы для этой таблицы. Относительная уникальность поля не имеет значения - даже на многолетнем товарном оборудовании я ожидаю, что запрос к этой таблице займет доли секунды.
вы можете использовать общее эмпирическое правило: оптимизируйте, когда это становится проблемой. Просто не используйте индекс, пока не заметите, что он вам нужен.
Из того, что вы говорите, не похоже, что индекс необходим. Эмпирическое правило заключается в том, что индексные поля часто используются в SELECTS для ускорения поиска, что, в свою очередь, (может) замедлять INSERTS и UPDATES.
На таком маленьком наборе записей, как ваш, я не думаю, что вы в любом случае увидите большую часть реального мира.
Если вы будете выполнять поиск по нему только два раза в месяц и это несколько строк, я бы посоветовал не индексировать его. Это все, но бесполезно.
Нет. Записей не так много, и они не будут часто запрашиваться. Не нужно индексировать.
Это действительно приговор. С такой маленькой таблицей вы можете достаточно быстро искать без индекса, так что вы можете обойтись и без него.
С другой стороны, стоимость создания индекса, который вам на самом деле не нужен, довольно низка, поэтому вы не сильно экономите, не делая этого.
Кроме того, если вы создадите индекс, вы застрахованы на будущее, если вдруг начнете получать 1000 новых записей в неделю. Возможно, вы достаточно знаете о ситуации, чтобы с уверенностью сказать, что этого никогда не произойдет, но требования могут измениться, когда вы меньше всего этого ожидаете.
РЕДАКТИРОВАТЬ: Что касается изменения требований, следует учитывать следующее: если БД действительно растет, а позже вы обнаружите, что вам нужен индекс, можете ли вы просто создать индекс и сделать это? Или вам также потребуется изменить много кода, чтобы использовать новый индекс?
Это зависит. Как ответили другие, существует компромисс между скоростью обновления таблицы и скоростью выбора. Обновление таблицы включает вставки, обновления и удаления в таблице.
Вы не ответили на один вопрос. Есть ли у таблицы первичный ключ и соответствующий индекс? Таблица без индексов обычно выигрывает от наличия хотя бы одного индекса. Самый распространенный способ получить этот индекс — объявить первичный ключ и полагаться на то, что СУБД сгенерирует соответствующий индекс.
Если в таблице нет кандидатов на первичный ключ, это обычно указывает на серьезный недостаток в дизайне таблицы. Это отдельная тема, и она должна стать предметом серьезного обсуждения.
