Kilka punktów:
Wygląda na to, że używasz tylko tego, co jest obecnie unikalne w tabeli i czynisz to jako kluczem podstawowym. To działa. A klucze naturalne mają pewne zalety, jeśli chodzi o zapytania ze względu na lokalizację. (Dane każdego użytkownika są przechowywane w tym samym obszarze). A ponieważ tabela jest pogrupowana według tego klucza, co eliminuje wyszukiwania danych, jeśli wyszukujesz według kolumn w podstawowym.
-
Jednak użycie naturalnego klucza podstawowego, takiego jak wybrany, ma również wady wydajności.
-
Użycie bardzo dużego klucza podstawowego spowoduje, że wszystkie inne indeksy będą bardzo duże w innodb, ponieważ klucz podstawowy jest zawarty w każdej wartości indeksu.
-
Używanie naturalnego klucza podstawowego nie jest tak szybkie jak klucza zastępczego dla INSERT, ponieważ oprócz tego, że jest większy, nie można go za każdym razem wstawiać na końcu tabeli. Musi wstawić w sekcji dla tego użytkownika i posta itp.
-
Ponadto, jeśli szukasz według czasu, najprawdopodobniej będziesz szukał po całej tabeli za pomocą klucza naturalnego, chyba że czas jest twoją pierwszą kolumną. klucze zastępcze są zwykle lokalne i często mogą być odpowiednie dla niektórych zapytań.
-
Używanie klucza naturalnego, takiego jak twój, jako klucza podstawowego, może być denerwujące. Co zrobić, jeśli chcesz odnieść się do konkretnego głosu? Potrzebujesz kilku pól. Jest też trochę trudny w użyciu z wieloma ORM-ami.
Oto odpowiedź
Utworzyłbym twój własny klucz zastępczy i używał go jako klucza podstawowego, zamiast polegać na wewnętrznym kluczu podstawowym innodb, ponieważ będziesz mógł go używać do aktualizacji i wyszukiwania.
ALTER TABLE tbl_rate
ADD id INT UNSIGNED NOT NULL AUTO_INCREMENT,
ADD PRIMARY KEY(id);
Ale jeśli utworzysz zastępczy klucz podstawowy, uczynię go również UNIKATOWYM. Ten sam koszt, ale wymusza poprawność.
ALTER TABLE tbl_rate
ADD UNIQUE ( user_id, post_id, type );
