Ограничение UNIQUE автоматически создает ИНДЕКС в поле (ах)?

Должен ли я определить отдельный индекс для emailстолбца (для целей поиска), или индекс добавляется «автоматически» вместе с UNIQ_EMAIL_USERограничением?

CREATE TABLE IF NOT EXISTS `customer` (
  `id` int(11) NOT NULL AUTO_INCREMENT,
  `user_id` int(11) NOT NULL,
  `first` varchar(255) NOT NULL,
  `last` varchar(255) NOT NULL,
  `slug` varchar(255) NOT NULL,
  `email` varchar(255) NOT NULL,
  `created_at` datetime NOT NULL,
  `updated_at` datetime NOT NULL,
  PRIMARY KEY (`id`),
  UNIQUE KEY `UNIQ_SLUG` (`slug`),
  UNIQUE KEY `UNIQ_EMAIL_USER` (`email`,`user_id`),
  KEY `IDX_USER` (`user_id`)
) ENGINE=InnoDB;

РЕДАКТИРОВАТЬ : как предложил Корбин, я запросил EXPLAIN SELECT * FROM customer WHERE email = 'address'пустую таблицу. Это результат, я не знаю, как его интерпретировать:

id select_type type possible_keys key  key_len ref  rows Extra
1  SIMPLE      ALL  NULL          NULL NULL    NULL 1    Using where

При добавлении IXD_EMAIL в таблицу тот же запрос показывает:

id select_type type possible_keys key       key_len ref   rows Extra
1  SIMPLE      ref  IDX_EMAIL     IDX_EMAIL 257     const 1    Using where

mysql sql indexing

— Gremo
источник

Ограничение UNIQUE технически не требует индекса ... но не уверен, как его определяет стандарт или как MySQL (какой бэкэнд, кстати?) Реализует. Все, что я могу быстро найти в MySQL вручную, это «УНИКАЛЬНЫЙ индекс создает такое ограничение, что все значения в индексе должны быть разными».

Вам необходимо реализовать и протестировать индивидуальные и покрывающие индексы (также известные как составные - более одного столбца). Это зависит от использования и данных.

— OMG Ponies

Я на 99% уверен, что он действительно создает индекс. Просто создайте таблицу с уникальным, а затем объясните выбор с помощью где.

— Corbin

@Corbin сделал это, как мне интерпретировать результат?

— gremo

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

— Corbin

115

Уникальный ключ является частным случаем индекса, действуя как обычный индекс с добавленной для проверки уникальности. Используя, SHOW INDEXES FROM customerвы можете увидеть, что ваши уникальные ключи на самом деле являются индексами типа B-дерева.

Композитный индекс на (email, user_id)достаточно, вам не нужен отдельный индекс только по электронной почте - MySQL может использовать самые левые части составного индекса. Могут быть некоторые пограничные случаи, когда размер индекса может замедлить ваши запросы, но вам не следует беспокоиться о них, пока вы действительно не столкнетесь с ними.

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

— пиотрм
источник

Итак, EXPLAINтест показывает ложные значения из-за пустой таблицы?

— gremo

Я не уверен, как вам удалось получить этот результат объяснения, я только что скопировал определение вашей таблицы, и в том же объяснении показан UNIQ_EMAIL_USER в качестве возможного ключа, не могли бы вы перепроверить его?

— piotrm

Хорошо, нашел трюк. Когда ограничение user_idсначала определяется с помощью, а затем emailоно не отображается в EXPLAIN. Вы в курсе?

— gremo

Это не работает, потому что электронная почта не является крайней левой частью пары (user_id, email). Вы не можете спуститься вниз по B-дереву, чтобы найти свою строку, используя только крайнюю правую часть.

— piotrm