Czy powinienem zdefiniować oddzielny indeks w email
kolumnie (do celów wyszukiwania), czy indeks jest dodawany „automatycznie” wraz z UNIQ_EMAIL_USER
ograniczeniem?
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
Odpowiedzi:
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 customer
moż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.
źródło
EXPLAIN
test pokazuje fałszywe wartości z powodu pustej tabeli?user_id
najpierw, a następnieemail
nie pojawia się wEXPLAIN
. Czy jesteś tego świadomy?