Mysql проблема индексации с несколькими 'или' и 'и'

Question

У меня большая база данных, которая используется для записи всех происходящих событий.Это похоже на систему продажи билетов.Теперь, поскольку я хранил данные с другим статусом, чтобы знать действие над определенным тикетом в одном столбце, я должен использовать несколько «или» в выражении, чтобы узнать текущий статус в тикете.

Например:1 для открытого билета, 2 для подтверждения, 3 для закрытого события.Теперь запрос для выбора всех событий с 1,2,3 будет:

SELECT * 
  FROM tbl_name 
 WHERE status IN (1, 2, 3) 
   AND event_id = 1;

Я создал индексы для поля id, а другой индекс event_status для event_id и status field.

Теперь, когда я запускаю EXPLAIN для этого запроса, он не использует индекс event_status, а использует другой существующий индекс, такой как event_status_dept, который состоит из event_id, status и отдела.

Если яиспользуйте только два поля в выражении IN i.e 'IN (1,2)', он использует индекс event_status, в противном случае он использует другой индекс, то есть event_status_dept.Я не знаю, что не так с моим заявлением.

Answer 1

Не думаю, что с вашим запросом что-то не так. Оптимизатор использует лучший индекс, который он может найти в соответствии с условиями в запросе и статистикой, которую он содержит. Индекс не эффективен, если более чем определенный процент записей удовлетворяет условию.

Пример: Если статистика оптимизатора говорит, что только 5% событий в таблице относятся к типам 1,2, это будет эффективный индекс, и он будет его использовать. Но если 70% событий относятся к типам 1,2,3, этот индекс не эффективен, и оптимизатор может использовать другой индекс или вообще не использовать его.

Answer 2

Использование нескольких индексов для доступа к таблице, как правило, очень неэффективно:

http://use -the-index-luke.com / sql / where-clause / search-for-range / index-merge-performance

Объединенный индекс, такой как ваш, для event_id, status, отдела - лучшее решение.

Однако MySQL имеет своего рода Index-Merge:

http://dev.mysql.com/doc/refman/5.5/en/index-merge-optimization.html