Czy UNIKALNE ograniczenie automatycznie tworzy INDEKS w polu (polach)?

Czy powinienem zdefiniować oddzielny indeks w emailkolumnie (do celów wyszukiwania), czy indeks jest dodawany „automatycznie” wraz z UNIQ_EMAIL_USERograniczeniem?

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;

EDYCJA : zgodnie z sugestią Corbina, o którą prosiłem EXPLAIN SELECT * FROM customer WHERE email = 'address'na pustym stole. Oto wynik, nie wiem, jak go zinterpretować:

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

Podczas dodawania IXD_EMAIL do tabeli to samo zapytanie pokazuje:

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

Unikalny klucz jest szczególnym przypadkiem indeksu, działającego jak zwykły indeks z dodatkiem sprawdzania niepowtarzalności. Używając SHOW INDEXES FROM customermożesz zobaczyć, że twoje unikalne klucze są w rzeczywistości indeksami typu B-drzewa.

Kompozytowy wskaźnik na (email, user_id)to wystarczy, nie trzeba osobnego indeksu tylko email - MySQL można używać lewostronne części z indeksu kompozytowego. Mogą wystąpić przypadki graniczne, w których rozmiar indeksu może spowolnić zapytania, ale nie powinieneś się nimi martwić, dopóki ich nie napotkasz.

Jeśli chodzi o testowanie użycia indeksu, należy najpierw wypełnić tabelę danymi, aby optymalizator uznał, że warto użyć tego indeksu.