Dit zou echt gemeten moeten worden, we kunnen wat "gissingen" doen op basis van wat we weten en wat we aannemen, maar dat zijn slechts gissingen.
U vermeldt niet of deze tabel InnoDB is, of MyISAM met dynamische rijen, of MyISAM met rijen van vaste lengte. Dat gaat een verschil maken.
Maar voor waarden zoals degene die je hebt gepost, '961637593864109_412954765521130' (31 tekens), ervan uitgaande dat u een karakterset van één byte gebruikt (bijv. latin1), of een karakterset die die specifieke tekens codeert in een enkele byte (bijv. utf8)...
Voor InnoDB en MyISAM dynamisch formaat is dat 31+1-8=24 extra bytes voor die rij. (BIGINT past in 8 bytes, een VARCHAR(31)-waarde van 31 tekens gebruikt 32 bytes.)
Voor een MyISAM-tabel met rijen van vaste lengte zou dat een verschil van 23 bytes per rij zijn. (Er is ruimte gereserveerd voor alle 31 tekens en de lengte hoeft niet te worden opgeslagen.)
Die primaire sleutelwaarde wordt ook in elke index herhaald, dus er is ook meer ruimte bij elke index.
Ervan uitgaande dat uw tabelrijen 120 bytes zijn met BIGINT, en de rijen 144 bytes met VARCHAR, is dat een 20% toenemen. Hoe groter uw rijen, hoe kleiner de procentuele stijging en vice versa.
Voor 1.000.000 rijen (ik wil zo zeggen "one meelyun rows" op dezelfde manier waarop Dr. Evil zijn pink in zijn mondhoek legt en zegt "één miljoen dollar") die extra 24 bytes per rij in totaal ongeveer 24 MB bedragen.
Maar het is niet echt zo gemakkelijk. In termen van InnoDB-ruimte is het een kwestie van hoe rijen in een blok kunnen "passen". Hoe groter de gemiddelde rijgrootte, hoe groter de hoeveelheid vrije ruimte in een blok.
Als je niets met de rijen doet, behalve ze op schijf opslaan, dan is het eigenlijk gewoon een toename van schijfruimte en extra tijd en ruimte voor back-ups.
Als hetzelfde aantal "144 byte" rijen in een blok passen als "120 byte" rijen, dan zul je geen verschil in ruimte zien. Maar als er minder rijen in een blok passen, zijn dat meer blokken, meer ruimte in de InnoDB-bufferpool, meer i/o, enz.
Voor zoekopdrachten van een enkele rij, hetzij op primaire sleutelwaarde, hetzij op een andere unieke indexzoekopdracht, zal het verschil verwaarloosbaar zijn.
Als je te maken hebt met grotere resultatensets, dan is dat extra geheugen voor het voorbereiden van de resultatenset, en extra bytes om naar de client over te zetten, enz.
Als de VARCHAR-sleutel zo is ontworpen dat "groepen" rijen die samen worden geopend hetzelfde leidende deel van de sleutelwaarde hebben, dan kan er met InnoDB daadwerkelijk enige prestatieverbetering zijn. Dat komt omdat de primaire sleutel de clustersleutel is... veel grotere kans dat de rijen die nodig zijn om aan een zoekopdracht te voldoen, zich in hetzelfde blok bevinden, in plaats van verspreid te zijn over een aantal blokken.
Het omgekeerde is dat als er invoegingen en verwijderingen worden uitgevoerd, er in sommige blokken meer vrije ruimte zal zijn. (Bij het verwijderen blijft de ruimte voor verwijderde rijen in het blok; om dat opnieuw te gebruiken, moet u een rij invoegen die dezelfde sleutelwaarde had (of op zijn minst een sleutelwaarde die dicht genoeg bij elkaar ligt om in hetzelfde blok te belanden) .) En met willekeurige invoegingen krijgen we bloksplitsingen.