Een paar punten:
Het klinkt alsof je gewoon gebruikt wat momenteel uniek is aan de tafel en dat als een primaire sleutel maakt. Dat werkt. En natuurlijke sleutels hebben enkele voordelen als het gaat om query's vanwege de plaats. (De gegevens voor elke gebruiker worden in hetzelfde gebied opgeslagen). En omdat de tabel is geclusterd door die sleutel, waardoor opzoekingen naar de gegevens worden geëlimineerd als u zoekt op de kolommen in de primaire.
-
Maar het gebruik van een natuurlijke primaire sleutel zoals u heeft gekozen, heeft ook nadelen voor de prestaties.
-
Het gebruik van een zeer grote primaire sleutel maakt alle andere indexen erg groot in innodb omdat de primaire sleutel in elke indexwaarde is opgenomen.
-
Het gebruik van een natuurlijke primaire sleutel is niet zo snel als een surrogaatsleutel voor INSERT's, omdat deze niet alleen groter is, maar ook niet elke keer aan het einde van de tabel kan worden ingevoegd. Het moet in de sectie voor die gebruiker en post enz. worden ingevoegd.
-
Als u op tijd zoekt, zoekt u hoogstwaarschijnlijk de hele tabel met een natuurlijke sleutel, tenzij tijd uw eerste kolom is. surrogaatsleutels zijn meestal lokaal voor de tijd en kunnen vaak precies goed zijn voor sommige vragen.
-
Het gebruik van een natuurlijke sleutel zoals die van u als primaire sleutel kan ook vervelend zijn. Wat als u naar een bepaalde stemming wilt verwijzen? Je hebt een paar velden nodig. Het is ook een beetje moeilijk te gebruiken met veel ORM's.
Hier is het antwoord
Ik zou je eigen surrogaatsleutel maken en deze als primaire sleutel gebruiken in plaats van te vertrouwen op de interne primaire sleutel van innodb, omdat je deze kunt gebruiken voor updates en opzoekacties.
ALTER TABLE tbl_rate
ADD id INT UNSIGNED NOT NULL AUTO_INCREMENT,
ADD PRIMARY KEY(id);
Maar als u een surrogaat-primaire sleutel maakt, zou ik uw sleutel ook UNIEK maken. Dezelfde kosten, maar het dwingt juistheid af.
ALTER TABLE tbl_rate
ADD UNIQUE ( user_id, post_id, type );