Правильное использование индекса базы данных?

#mysql #database #indexing

Вопрос:

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

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

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

Ответ №1:

Я думаю, что настоящий ответ на этот вопрос — «это зависит».

По каким полям вы проводите поиск? Например, если поисковый запрос пользователя должен искать в полях имя, фамилию, адрес электронной почты, номер телефона, почтовый индекс и т. Д…. Возможно, нецелесообразно индексировать каждое поле, и это не сильно поможет.

Сколько у вас записей? В общем случае, чем больше таблица, тем медленнее поиск без индекса, но тем больше времени займет вставка/обновление с индексом.

Как часто пользователи выполняют поиск? Часто ли это происходит — например, каждые 5 минут или пару раз в день?

Когда дело доходит до индексации, также важна доступность. Мощность относится к уникальности данных, содержащихся в столбце. Низкая мощность может не стоить индексирования. Подумайте о логическом поле, которое может быть либо истинным, либо ложным, и 90% ваших записей имеют значение true, и большую часть времени вы запрашиваете в этом поле истинные значения. Индексировать это поле, скорее всего, бессмысленно.

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

Вы правы, задавая этот вопрос, потому что люди иногда слепо индексируют любое поле, что увеличит размер базы данных и снизит производительность вставки/обновления. Если бы это был я, и я хотел регулярно выполнять поиск по определенному полю, я бы, скорее всего, проиндексировал его, если select бы производительность была низкой без индекса.

Комментарии:

1. Я планировал индексировать только одно поле «имя». И в данных не так много уникальности, поэтому поисковый запрос должен искать все данные в таблице. Количество данных в таблице также довольно велико. Эти факторы могут быть явным признаком введения индексации. Но, с другой стороны, частота вставки намного выше, чем извлечения, почти слишком высока. Но еще один фактор, который следует учитывать, заключается в том, что пользователи не занимаются вставками, они занимаются только извлечением, поэтому было бы практично индексировать таблицу, чтобы облегчить им жизнь. Так что я все еще довольно нерешителен.

2. Попробуйте проиндексировать его, а затем измерьте производительность как поисковых запросов, так и запросов на вставку. Возможно, поисковые запросы значительно улучшились, и запросы на вставку не слишком сильно пострадали. Я предполагаю name , что это строка, и в этом случае вы, возможно, захотите запросить ее либо по точному совпадению, либо с name LIKE "smith%" и без name LIKE "%smith%" (я не верю, что последнее будет использовать индекс).

3. Конечно, я попробую это сделать.

4. Индексы не должны сильно замедлять скорость вставки/обновления, когда таблица «больше». Если это уместно, «составной» INDEX(color_id, category_id) может быть намного лучше, чем отдельные индексы.

5. Проиндексировал таблицу и теперь она работает намного быстрее, и никаких проблем, связанных с операциями обновления/вставки, нет. Спасибо всем!

Ответ №2:

Вы не указали, какими данными вы располагаете. Если есть отличительные ключевые слова, которые легко помещаются в столбец-например, марка и модель транспортного средства, — то индексы, вероятно, будут очень полезны.

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

Для множества случайных слов, обозначающих стиль одежды, номер модели, стиль шасси, название подразделения и т. Д., Добавьте информацию в TEXT столбец и используйте FULLTEXT индекс вместе с MATCH...AGAINST -это будет быстро. Но у него есть некоторые ограничения. Например, Ford F150 работает хорошо, но Ford F-150 будет трудно найти.

Избегайте LIKE '%foo%' ; ведущий подстановочный знак предотвращает использование любого индекса.

Сделайте индексы для пользователей; не беспокойтесь о вставках/обновлениях.

(И я согласен с большинством из того, что говорит мистер Кэррот.)

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