Должен ли я определить отдельный индекс для 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
Ответы:
Уникальный ключ является частным случаем индекса, действуя как обычный индекс с добавленной для проверки уникальности. Используя,
SHOW INDEXES FROM customer
вы можете увидеть, что ваши уникальные ключи на самом деле являются индексами типа B-дерева.Композитный индекс на
(email, user_id)
достаточно, вам не нужен отдельный индекс только по электронной почте - MySQL может использовать самые левые части составного индекса. Могут быть некоторые пограничные случаи, когда размер индекса может замедлить ваши запросы, но вам не следует беспокоиться о них, пока вы действительно не столкнетесь с ними.Что касается тестирования использования индекса, вы должны сначала заполнить свою таблицу некоторыми данными, чтобы оптимизатор решил, что действительно стоит использовать этот индекс.
источник
EXPLAIN
тест показывает ложные значения из-за пустой таблицы?user_id
сначала определяется с помощью, а затемemail
оно не отображается вEXPLAIN
. Вы в курсе?