これは、使用されているDBMSエンジンに完全に依存します。 SQL自体は、物事が物理的にどのように格納されるかを義務付けているのではなく、論理的にどのように見えるかを義務付けています。
たとえば、DBMSは、行に最大サイズのスペースと、長さを格納するための追加のバイトを割り当てる場合があります。その場合、varchar(10)には大きな違いがあります。 およびvarchar(1000) 行ごとにかなりのスペースを浪費するためです。
または、varcharにバッファプールを使用することもできます。 データを取得し、長さとバッファプールの「開始アドレス」のみを行に格納します。その場合、すべての行にvarcharの同じサイズの情報が格納されます。 サイズに関係なく列ですが、その列の実際のデータを抽出するための追加の手順があります（バッファープールへのリンクに従います）。
varcharを使用する理由 それがvarcharという名前の理由です 。可変サイズのデータ要素を保存できます。通常、char(10) 何があっても、10文字を表示します。短い文字を挿入すると、スペースが埋め込まれます。抽出するときに末尾のスペースを削除することはできますが、保存するデータが実際に"hello "である場合は、うまく機能しません。 、 with 保存したい後続スペース。
適切なDBMSエンジンは、varcharの最大サイズに応じてトレードオフを決定する場合があります。 桁。短いものの場合は、行にインラインで格納し、サイズに応じて余分なバイトを消費する可能性があります。
長いvarchar 列を別のバッファプールに「アウトソーシング」して、行の読み取りを効率的に維持することができます（少なくとも必要になるまで 大きなvarchar とにかく、列）。
より的を絞った回答を得るために、特定のDBMSに再度質問する必要があります。
または、正直なところ、最大サイズのみを格納するようにデータベースを設計します。 10だとわかっている場合は、varchar(1000) 無駄です。将来、列を拡大する必要がある場合は、 今ではなく、今がその時です（YAGNI
を参照してください。 。
MySQLの場合は、Chapter 14 Storage Engines
オンラインドキュメントの。
MySQLが使用するさまざまなストレージエンジン（InnoDBやMyISAMなど）をカバーしており、十分に深く見ると、情報が物理的にどのように保存されているかを確認できます。
たとえば、MyISAMでは、テーブルに可変長データが存在します（varchar 含まれている）は通常、動的テーブル
を意味します 。これは、前述のバッファプールの概念とほぼ同様のスキームに従いますが、可変サイズの列で無駄になるスペースが少なくなるという利点と、行が断片化される可能性があるという欠点があります。
他のストレージ形式（読み取り専用テーブルにのみ実際に使用されるため、圧縮形式は割引）は静的なもの 、データは単一の物理行に格納されます。
InnoDBの物理構造に関する情報は、にあります。ここ 。 AntelopeまたはBarracudaファイル形式のどちらを使用するかに応じて、動的と静的のMyISAMの区別と同様に、「すべての情報は物理行」または「バッファプール」の状況になります。