Dette ville virkelig skulle måles, vi kan lave nogle "gæt" baseret på, hvad vi ved, og hvad vi antager, men det er bare gæt.
Du nævner ikke, om denne tabel er InnoDB eller MyISAM med dynamiske rækker eller MyISAM med rækker med fast længde. Det kommer til at gøre en forskel.
Men for værdier som den, du postede, '961637593864109_412954765521130' (31 tegn), forudsat at du bruger et enkelt byte-tegnsæt (f.eks. latin1) eller et tegnsæt, der koder disse særlige tegn til en enkelt byte (f.eks. utf8)...
For dynamiske InnoDB- og MyISAM-formater er det 31+1-8=24 ekstra bytes for den række. (BIGINT passer ind i 8 bytes, en VARCHAR(31)-værdi på 31 tegn vil bruge 32 bytes.)
For MyISAM-tabel med rækker med fast længde vil det være en forskel på 23 bytes pr. række. (Plads er reserveret til alle 31 tegn, og længden behøver ikke at blive gemt.)
Den primære nøgleværdi vil også blive gentaget i hvert indeks, så der er også øget plads med hvert indeks.
Hvis du antager, at dine tabelrækker er 120 bytes ved brug af BIGINT, og rækkerne er 144 bytes med VARCHAR, er det 20 % øge. Jo større dine rækker er, jo mindre er stigningen i procent og omvendt.
For 1.000.000 rækker (jeg vil så gerne sige "one meelyun rows" på samme måde som Dr. Evil sætter sin lillefinger i mundvigen og siger "en million dollars"), er de ekstra 24 bytes pr. række i alt omkring 24MB.
Men det er egentlig ikke så nemt. Med hensyn til InnoDB-plads er det et spørgsmål om, hvordan rækker "passer" ind i en blok. Jo større den gennemsnitlige rækkestørrelse er, jo større er mængden af ledig plads i en blok.
Hvis du ikke gør noget med rækkerne udover at gemme dem på disken, så er det egentlig bare en forøgelse af diskpladsen og ekstra tid og plads til sikkerhedskopier.
Hvis det samme antal "144 byte" rækker passer i en blok som "120 byte" rækker, så vil du ikke se nogen forskel i rummet. Men hvis færre rækker passer i en blok, er det flere blokke, mere plads i InnoDB-bufferpuljen, mere i/o osv.
For forespørgsler på en enkelt række, enten efter primær nøgleværdi eller ved et andet unikt indeksopslag, vil forskellen være ubetydelig.
Hvis du har at gøre med større resultatsæt, så er det ekstra hukommelse til at forberede resultatsættet og ekstra bytes til at overføre til klienten osv.
Hvis VARCHAR-nøglen er designet på en sådan måde, at "grupper" af rækker, der tilgås sammen, har den samme førende del af nøgleværdien, så kan der med InnoDB faktisk være en forbedring af ydeevnen. Det er fordi den primære nøgle er klyngenøglen... meget større chance for, at de rækker, der er nødvendige for at opfylde en forespørgsel, er i samme blok, i stedet for at blive spredt ud over en masse blokke.
Det omvendte er, at hvis der udføres indsættelser og sletninger, vil der være mere ledig plads i nogle blokke. (Med sletningerne forbliver pladsen til slettede rækker i blokken; for at få den genbrugt, skal du indsætte en række, der havde den samme nøgleværdi (eller i det mindste en nøgleværdi tæt nok på, at den lander i samme blok .) Og med tilfældige indsættelser får vi blokopdelinger.