Et par punkter:
Det lyder, som om du bare bruger det, der i øjeblikket er unikt ved bordet, og gør det som en primær nøgle. Det virker. Og naturlige nøgler har nogle fordele, når det kommer til forespørgsler på grund af lokalitet. (Dataene for hver bruger er gemt i samme område). Og fordi tabellen er grupperet af den nøgle, som eliminerer opslag til dataene, hvis du søger efter kolonnerne i den primære.
-
Men at bruge en naturlig primær nøgle, som du har valgt, har også ulemper for ydeevnen.
-
Brug af en meget stor primærnøgle vil gøre alle andre indekser meget store i innodb, fordi den primære nøgle er inkluderet i hver indeksværdi.
-
At bruge en naturlig primærnøgle er ikke så hurtigt som en surrogatnøgle til INSERT'er, fordi den ud over at være større ikke bare kan indsætte i slutningen af tabellen hver gang. Det skal indsættes i sektionen for den pågældende bruger og poste osv.
-
Også, hvis du søger efter tid, vil du højst sandsynligt søge over hele tabellen med en naturlig nøgle, medmindre tid er din første kolonne. surrogatnøgler har en tendens til at være lokale for tid og kan ofte være helt rigtige til nogle forespørgsler.
-
Det kan også være irriterende at bruge en naturlig nøgle som din som en primær nøgle. Hvad hvis du vil henvise til en bestemt stemme? Du skal bruge et par felter. Det er også lidt svært at bruge med mange ORM'er.
Her er svaret
Jeg ville oprette din egen surrogatnøgle og bruge den som en primær nøgle i stedet for at stole på innodbs interne primærnøgle, fordi du vil være i stand til at bruge den til opdateringer og opslag.
ALTER TABLE tbl_rate
ADD id INT UNSIGNED NOT NULL AUTO_INCREMENT,
ADD PRIMARY KEY(id);
Men hvis du opretter en primær surrogatnøgle, vil jeg også gøre din nøgle til en UNIK. Samme pris, men det håndhæver korrektheden.
ALTER TABLE tbl_rate
ADD UNIQUE ( user_id, post_id, type );