11

MySQL のドキュメントではこの問題が少し不明確であるため、これら 2 つのデータ型によって実際にどのくらいのストレージ スペースが占有されるのか疑問に思っています。

CHAR(M) M × w バイト、0 <= M <= 255。ここで、w は文字セットの最大長の文字に必要なバイト数です。

VARCHAR(M)、VARBINARY(M) 列の値が 0 ～ 255 バイトを必要とする場合は L + 1 バイト、値が 255 バイトを超える可能性がある場合は L + 2 バイト

これは、utf8 でエンコードされたデータベースを考えると、CHAR は常に 1 文字あたり 32 ビットを使用するのに対し、VARCHAR は格納されている文字の実際のバイト長に応じて 8 ～ 32 ビットを使用することを暗示しているようです。あれは正しいですか？または、VARCHAR は 8 ビットの文字幅を意味し、マルチオクテットの UTF8 文字を格納すると、実際には VARCHAR から複数の「文字」が消費されますか? それとも、VARCHAR も常に 1 文字あたり 32 ビットを格納しますか? 非常に多くの可能性。

以前はそれほど心配する必要はありませんでしたが、メモリ内の一時テーブルのサイズ制限に達し始めており、MySQL の使用可能なプールを (2 回目) 増やす必要は必ずしもありません。

4

1 に答える 1

12

CHARどちらも文字数をVARCHARカウントします。どちらも、文字エンコーディングと長さを考慮して、必要になる可能性のある最大ストレージをカウントします。ASCII の場合、1 文字あたり 1 バイトです。UTF-8 の場合、これは 1 文字あたり 3 バイトです ( MySQL の Unicode サポートは何らかの理由で制限されており、UTF-8 で 4 バイトを必要とする Unicode 文字をサポートしていないため、期待どおりの 4 バイトではありません)。これまでのところ、CHARとVARCHARは同じです。

さて、CHAR先に進み、この量のストレージを予約します。

VARCHAR代わりに、この最大ストレージが 256 未満か 256 以上かに応じて、1 バイトまたは 2 バイトが割り当てられます。また、エントリが占有する実際の容量は、これらの 1 バイトまたは 2 バイトに、文字列が実際に占有する容量を加えたものです。

興味深いことに、これにより 85 が UTF-8 のマジック ナンバーになりますVARCHAR。

  • VARCHAR(85)85 UTF-8 文字の最大可能長は 3 × 85 = 255 であるため、長さとして 1 バイトを使用します。
  • VARCHAR(86)86 UTF-8 文字の最大可能長は 3 × 86 = 258 であるため、長さとして 2 バイトを使用します。
于 2012-04-10T00:35:50.630 に答える