Detta skulle verkligen behöva mätas, vi kan göra några "gissningar" baserat på vad vi vet och vad vi antar, men det är bara gissningar.
Du nämner inte om den här tabellen är InnoDB, eller MyISAM med dynamiska rader, eller MyISAM med fasta rader. Det kommer att göra skillnad.
Men för värden som det du postade, '961637593864109_412954765521130' (31 tecken), förutsatt att du använder en enkelbyte-teckenuppsättning (t.ex. latin1) eller en teckenuppsättning som kodar dessa specifika tecken till en enda byte (t.ex. utf8)...
För dynamiska InnoDB- och MyISAM-format är det 31+1-8=24 extra byte för den raden. (BIGINT ryms i 8 byte, ett VARCHAR(31)-värde på 31 tecken kommer att använda 32 byte.)
För MyISAM-tabeller med rader med fast längd skulle det vara en skillnad på 23 byte per rad. (Utrymmet är reserverat för alla 31 tecken, och längden behöver inte lagras.)
Det primära nyckelvärdet kommer också att upprepas i varje index, så det finns också ökat utrymme med varje index.
Om du antar att dina tabellrader är 120 byte med BIGINT, och raderna är 144 byte med VARCHAR, är det 20 % öka. Ju större rader du har, desto mindre är ökningen i procent och vice versa.
För 1 000 000 rader (jag vill så gärna säga "one meelyun rows" på samma sätt som Dr. Evil sätter sitt rosa finger i mungipan och säger "en miljon dollar") att extra 24 byte per rad totalt blir cirka 24MB.
Men det är inte riktigt så lätt. När det gäller InnoDB-utrymme är det en fråga om hur rader "passar" in i ett block. Ju större den genomsnittliga radstorleken är, desto större mängd ledigt utrymme blir det i ett block.
Om du inte gör något med raderna förutom att lagra dem på disk, så är det egentligen bara en ökning av diskutrymmet och extra tid och utrymme för säkerhetskopiering.
Om samma antal "144 byte"-rader passar i ett block som "120 byte"-rader, kommer du inte att se någon skillnad i utrymme. Men om färre rader får plats i ett block är det fler block, mer utrymme i InnoDB-buffertpoolen, mer i/o osv.
För frågor på en enskild rad, antingen efter primärnyckelvärde eller genom någon annan unik indexsökning, kommer skillnaden att vara försumbar.
Om du har att göra med större resultatuppsättningar, då är det extra minne för att förbereda resultatuppsättningen, och extra byte att överföra till klienten, etc.
Om VARCHAR-nyckeln är utformad på ett sådant sätt att "grupper" av rader som nås tillsammans har samma inledande del av nyckelvärdet, kan det faktiskt bli en viss prestandaförbättring med InnoDB. Det beror på att primärnyckeln är klusternyckeln... mycket större chans att raderna som behövs för att tillfredsställa en fråga finns i samma block, snarare än att de är utspridda över ett gäng block.
Det omvända är att om det görs insättningar och raderingar kommer det att finnas mer ledigt utrymme i vissa block. (Med borttagningarna förblir utrymmet för borttagna rader i blocket; för att få det återanvänt måste du infoga en rad som hade samma nyckelvärde (eller åtminstone ett nyckelvärde tillräckligt nära för att den landar i samma block .) Och med slumpmässiga inlägg kommer vi att få blockdelningar.