これは実際に測定する必要があります。私たちが知っていることと私たちが想定していることに基づいていくつかの「推測」を行うことができますが、それらは単なる推測です。
このテーブルがInnoDBであるか、動的行を使用するMyISAMであるか、固定長行を使用するMyISAMであるかについては言及しません。それはいくつかの違いを生むでしょう。
ただし、投稿したような値の場合は、'961637593864109_412954765521130' （31文字）、1バイトの文字セット（例：latin1）、またはそれらの特定の文字を1バイトにエンコードする文字セット（例：utf8）を使用していると仮定します...
InnoDBおよびMyISAM動的形式の場合、その行には31 + 1-8=24バイト余分になります。 （BIGINTは8バイトに収まり、31文字のVARCHAR（31）値は32バイトを使用します。）
行が固定されているMyISAMテーブルの場合、1行あたり23バイトの差になります。 （スペースは31文字すべてに予約されており、長さを格納する必要はありません。）
その主キー値もすべてのインデックスで繰り返されるため、各インデックスのスペースも増えます。
テーブルの行がBIGINTを使用して120バイトであり、行がVARCHARを使用して144バイトであると仮定すると、これは 20％ 増加。行が大きいほど、増加率は小さくなり、その逆も同様です。
1,000,000行（Evil博士が小指をこの口の隅に置いて「100万ドル」と言うのと同じように「1meelyun行」と言いたい）の場合、1行あたり24バイト余分に合計すると約24MBになります。
しかし、それはそれほど簡単ではありません。 InnoDBスペースに関しては、行がブロックにどのように「収まる」かが問題になります。平均行サイズが大きいほど、ブロック内の空き領域の量が多くなります。
行をディスクに保存する以外に何もしない場合、それは実際にはディスクスペースの増加であり、バックアップのための余分な時間とスペースです。
「120バイト」の行と同じ数の「144バイト」の行が1つのブロックに収まる場合、スペースに違いは見られません。ただし、ブロックに収まる行が少ない場合は、ブロックが多くなり、InnoDBバッファープールのスペースが増え、I/Oが増えます。
主キー値またはその他の一意のインデックスルックアップによる単一行のクエリの場合、違いはごくわずかです。
より大きな結果セットを処理している場合、それは結果セットを準備するための追加のメモリ、およびクライアントに転送するための追加のバイトなどです。
一緒にアクセスされる行の「グループ」がキー値の同じ先頭部分を持つようにVARCHARキーが設計されている場合、InnoDBを使用すると、実際にパフォーマンスが向上する可能性があります。これは、主キーがクラスターキーであるためです...クエリを満たすために必要な行が、多数のブロックに分散されるのではなく、同じブロック内にある可能性がはるかに高くなります。
逆に、挿入と削除が実行された場合、一部のブロックにはより多くの空き領域があります。 （削除すると、削除された行のスペースはブロック内に残ります。それを再利用するには、同じキー値（または少なくとも同じブロックに収まるほど近いキー値）を持つ行を挿入する必要があります。）ランダムに挿入すると、ブロック分割が行われます。