Индекс MySQL по столбцам таблицы

#mysql #performance #indexing

#mysql #Производительность #индексирование

Вопрос:

Я использую версию MySQL 8. Предположим, у меня есть таблица, то есть событие, и в ней около 15 столбцов. Предположим, что имена столбцов взяты из a, b, c… до m с типом данных varchar. Это основная таблица, поэтому в ней есть однозначные записи. Я предоставил панель мониторинга для этой таблицы, и клиент может выбирать поля для фильтрации записей в соответствии с их потребностями.

Для этого фильтра применяются 12 полей. Запрос создается на основе выбранных полей.

Если выбрано поле a, то запрос будет похож select * from event where a = <some value> .

Если выбраны b и c, то запрос будет выглядеть select *from event where b= <some value> and c= <some value>

Итак, можете ли вы предложить мне, как я могу создать индекс для лучшей оптимизации?

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

1. Сначала вы должны уточнить, какие запросы dashhoard будет отправлять в mysql. Большинство панелей мониторинга не просто запрашивают источник данных для каждого изменения фильтра, это было бы очень неэффективно.

2. @Shadow, да, вопрос обновлен, вы правы, но в этом случае мы отправляем запросы на основе выбранных полей.

3. INDEX(a) для первого запроса. INDEX(b,c) или INDEX(c,b) для второго. Но я подозреваю, что ваш вопрос требовал большего??

4. @RickJames спасибо за ваше предложение, я следил за вашим блогом для индексации. это был просто пример, который я поставил под сомнение. Клиент может использовать любое поле из 12 полей для фильтрации записей из панели мониторинга. Они могут выбирать, как a and b and c , e and g , k and a and d .

5. @5a01d01P вы должны оптимизировать свою панель мониторинга, чтобы не делать этого, или использовать установленное решение для построения графиков, в котором уже есть эта функция! Поверьте мне, вы можете вывести из строя свой сервер базы данных, если не будете осторожны!

Ответ №1:

Существует ограничение на количество индексов, которые вы можете иметь в таблице — как абсолютный предел (64), так и практический предел (намного меньше).

Я предлагаю вам начать с 12 «составных» индексов с 2 столбцами. Имейте разные начальные столбцы для каждого из 12. Имейте «вероятный» второй столбец.

Со временем следите за тем, что обычно выбирают пользователи, и соответственно добавляйте / вычитайте индексы.

Имейте в виду эти вещи:

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

Дополнительные советы (которые вы, кажется, нашли): http://mysql.rjweb.org/doc.php/index_cookbook_mysql

INDEX(a,b) сделает довольно хорошую работу для WHERE a=1 AND B=2 AND c=3 . Это будет не так хорошо, как INDEX(a,b,c) . Но я предполагаю, что вам нужно идти на компромиссы — будьте довольны «довольно хорошо»; вы не можете достичь «идеального» во всех случаях.