DB skal vedligeholde et B-Tree (eller en lignende struktur) med nøglen på en måde at få dem bestilt.
Hvis nøglen er hashed og gemt i B-Tree, ville det være fint at tjekke unikheden hurtigt af nøglen -- nøglen kan stadig slås op effektivt. Men du ville ikke være i stand til at søge effektivt efter område af data (f.eks. med LIKE ), fordi B-træet ikke længere er ordnet i henhold til strengværdien.
Så jeg tror, at de fleste DB virkelig gemmer strengen i B-træet, som kan (1) tage mere plads end numeriske værdier og (2) kræver, at B-træet genafbalanceres hvis nøgler er indsat i vilkårlig rækkefølge (ingen forestilling om stigende værdi som med numerisk pk).
straffen i praksis kan variere fra ubetydelig til enorm. Det hele afhænger af brugen, antallet af rækker, den gennemsnitlige størrelse af strengnøglen, de forespørgsler, der forbinder tabellen osv.