Skip navigation links
6.6 カラムに適した型の選択 »
Section Navigation      [Toggle]

6.5. データ型のストレージ要件

MySQL にサポートされているデータ型が必要とする記憶容量がカテゴリごとにリストされています。

MyISAM テーブル内の行の最大サイズは 65,535 バイトです。(ただし、BLOB または TEXT カラムはそれぞれ、このサイズに対して 9 から 12 バイトしか占有しません。)この制限は、ほかのストレージエンジンによっても共有されることがあります。詳細については、Storage Engines を参照してください。

重要項目

NDBCLUSTER ストレージエンジンを使用しているテーブルの場合、ストレージ要件を計算する際に 4 バイト整列という要素を考慮に入れる必要があります。これは、すべての NDB データ格納が 4 バイトの倍数単位で行われるという意味になります。したがって、NDB 以外のストレージエンジンを使用してテーブルに 15 バイトを取り込むカラムには、NDB テーブル内に 16 バイトのストレージが必要になります。この要求は、この節で紹介されるほかのすべての条件に当てはまります。たとえば、NDBCLUSTER テーブルでは、TINYINT、SMALLINT、MEDIUMINT、および INTEGER (INT) の各カラム型は、4 バイト整列のために 1 つのレコードにつき 4 バイトのストレージを必要とします。

BIT 型は 4 バイトで配置されないため、この規則には当てはまりません。MySQL Cluster テーブルでは、BIT(M) カラムは M ビットのストレージスペースを取ります。ただし、テーブル定義に 1 つ以上の BIT カラム (最高 32 個の BIT カラム) が含まれる場合、NDBCLUSTER は 1 行につき 4 バイト (32 ビット) を確保します。テーブル定義に 33 個以上の BIT カラム (最高 64 個のカラム) が含まれる場合、NDBCLUSTER は 1 行につき 8 バイト (64 ビット) を確保します。

また、NULL そのものがストレージスペースを必要としなくても、テーブル定義に NULL として定義されたカラム (最高 32 個の NULL カラム) が含まれる場合、NDBCLUSTER は 1 行につき 4 バイトを確保します。(MySQL Cluster テーブルが 33 から 64 個の NULL カラムで定義されている場合は、1 行につき 8 バイトが確保されます。)

MySQL Cluster テーブルのストレージ要件を計算するときは、NDBCLUSTER ストレージエンジンを使用するすべてのテーブルが主キーを必要とすることも覚えておいてください。ユーザーが主キーを定義しない場合は、「隠し」主キーが NDB ストレージエンジンによって作成されます。この隠れ主キーは 1 つのテーブルレコードに付き 31 から 35 バイトを消費します。

NDB ストレージ要件を見積もる際には ndb_size.pl ユーティリティーが役に立ちます。この Perl スクリプトは現在の MySQL (非クラスタ) データベースに接続し、そのデータベースが NDBCLUSTER ストレージエンジンを使用すると、どれくらいの容量が必要になるかについてのレポートを作成します。詳細については、ndb_size.pl を参照してください。

数値型が必要とする記憶容量

Data Type 記憶容量
TINYINT 1 バイト
SMALLINT 2 バイト
MEDIUMINT 3 バイト
INT, INTEGER 4 バイト
BIGINT 8 バイト
FLOAT(p) 0 <= p <= 24 の場合は 4 バイト、25 <= p <= 53 の場合は 8 バイト
FLOAT 4 バイト
DOUBLE [PRECISION], REAL 8 バイト
DECIMAL(M,D), NUMERIC(M,D) 変動; 後の説明を参照
BIT(M) 約 (M+7)/8 バイト

DECIMAL (と NUMERIC) カラムの値は、少数第 9 位（10 基準）の桁を 4 バイトにパックするバイナリフォーマットを利用して表現されます。各値の整数部と端数部の格納は別々に決定されます。9 桁の倍ごとに 4 バイト、「余りの」 桁には 4 バイトの端数容量がそれぞれ必要です。余りの桁に必要なストレージ要件を次の表に示します。

余り桁数 バイト数
0 0
1 1
2 1
3 2
4 2
5 3
6 3
7 4
8 4

日付と時刻型が必要とする記憶容量

Data Type 記憶容量
DATE 3 バイト
TIME 3 バイト
DATETIME 8 バイト
TIMESTAMP 4 バイト
YEAR 1 バイト

表に示したストレージ要件は、MySQL が時間値を表現する方法によって決まります。

  • DATE: DD + MM×32 + YYYY×16×32 としてパックされた 3 バイトの整数

  • TIME: DD×24×3600 + HH×3600 + MM×60 + SS としてパックされた 3 バイトの整数

  • DATETIME: 次の 8 バイト

    • YYYY×10000 + MM×100 + DD としてパックされた 4 バイトの整数

    • HH×10000 + MM×100 + SS としてパックされた 4 バイトの整数

  • TIMESTAMP: 基準時刻 ('1970-01-01 00:00:00' UTC) からの秒数を表す 4 バイトの整数

  • YEAR: 1 バイトの整数

文字列型の記憶容量

次の表では、M は宣言されたカラムの長さを、非バイナリ列型の場合は文字数で、バイナリ列型の場合はバイト数で表します。L は指定された文字列値の実際の長さをバイト数で表します。

Data Type 記憶容量
CHAR(M) M × w バイト、0 <= M <= 255、この場合の w はキャラクタセット内の最大長の文字に必要なバイト数
BINARY(M) M バイト、0 <= M <= 255
VARCHAR(M)、VARBINARY(M) カラム値が 0 から 255 バイトを必要とする場合は L + 1 バイト、カラム値が 256 バイト以上を必要とする可能性がある場合は L + 2 バイト
TINYBLOB, TINYTEXT L + 1 バイト、この場合 L < 28
BLOB, TEXT L + 2 バイト、この場合 L < 216
MEDIUMBLOB, MEDIUMTEXT L + 3 バイト、この場合 L < 224
LONGBLOB, LONGTEXT L + 4 バイト、この場合 L < 232
ENUM('value1','value2',...) 列挙値により 1 か 2 バイト (最高 65,535 値)
SET('value1','value2',...) セットメンバーの数により、1、2、3、4、または 8 バイト (最高 64 メンバー)

可変長の文字列型は、長さ接頭辞が付いたデータとして格納されます。長さ接頭辞にはデータ型に応じて 1 から 4 バイトが必要で、接頭辞の値は L (文字列のバイト長) です。たとえば、MEDIUMTEXT 値のストレージには、値を格納するための L バイトに加えて、値の長さを格納するための 3 バイトが必要です。

特定の CHAR、VARCHAR、または TEXT カラム値を格納するためのバイト数を計算するには、そのカラムに使用されるキャラクタセットと、値にマルチバイト文字が含まれるかどうかを考慮に入れる必要があります。特に、utf8 Unicode キャラクタセットの使用時は、すべての utf8 文字が同じ数のバイトを使用し、1 文字につき最高 3 バイトを必要とするとは限らないことに注意してください。utf8 文字の異なるカテゴリに利用される格納についての概要は、Unicode Support を参照してください。

VARCHAR、VARBINARY、そして BLOB と TEXT 型は可変長型です。それぞれが必要とする記憶容量はこれらの要因によって決まります。

  • カラム値の実長さ

  • カラムの可能最大長さ

  • カラムに使用するキャラクタセット (一部のキャラクタセットにはマルチバイト文字が含まれているため)

たとえば、VARCHAR(255) カラムには最大 255 文字の長さの文字列を格納できます。そのカラムが latin1 キャラクタセット (1 文字あたり 1 バイト) を使うとすると、実際に必要なストレージは文字列の長さ (L) に、文字列の長さを記録するための 1 バイトを加えた大きさとなります。文字列 'abcd' の場合、L は 4 で、ストレージ要件は 5 バイトになります。同じカラムが代わりにダブルバイトキャラクタセット ucs2 を使用するように宣言されている場合、ストレージ要件は 10 バイトになります。'abcd' の長さは 8 バイトで、カラムの最大長が 255 よりも大きい (最高 510 バイト) ため、長さを格納するために 2 バイト必要になります。

注意

VARCHAR または VARBINARY カラムに格納できる有効な最大バイト数は最大行サイズ (65,535 バイト、すべてのカラムで共有される) によって決まります。マルチバイト文字を格納する VARCHAR カラムの場合、有効な最大文字数 はこれよりも少なくなります。たとえば、utf8 の文字は 1 文字につき最高 3 バイトを必要とする場合があるため、utf8 のキャラクタセットを使用する VARCHAR カラムは、最大 21,844 文字になるように宣言できます。

MySQL 5.1 の NDBCLUSTER ストレージエンジンは可変幅カラムをサポートします。これは、そのような値が 4 バイトにそろっている場合以外は、MySQL Cluster テーブルの VARCHAR カラムが、ほかのストレージエンジンを利用したときと同じ容量を必要とするという意味になります。したがって、latin1 キャラクタセットを使用して VARCHAR(50) カラムに格納された文字列 'abcd' には、8 バイト (MyISAM テーブル内の同じカラム値に必要な 6 バイトではない) が必要になります。これは、VARCHAR(50) カラムが、格納される文字列の長さに関係なく、1 つのレコードにつき 52 バイトを必要としていた NDBCLUSTER の初期バージョンからの変更点を表しています。

TEXT と BLOB カラムは、TEXT カラム内のそれぞれの行が 2 つの部分で構成される、NDB Cluster ストレージエンジンの中で異なる方法で実行されます。そのうちの 1 つは固定サイズ (256 バイト) で、実際に元のテーブルに格納されます。もう 1 つは 256 バイトを超えるデータで構成され、隠しテーブルに格納されます。2 つめのテーブルの行の長さは常に 2,000 バイトです。つまり、size <= 256 (size は行のサイズを表す) の場合、TEXT カラムのサイズは 256 となり、そうでない場合のサイズは 256 + size + (2000 – (size – 256) % 2000) となります。

ENUM オブジェクトのサイズは異なる列挙値の数によって決定します。1 バイトは、最大 255 の値を持つ列挙に使用されます。2 バイトは、256 から 65,535 の間の値を持つ列挙に使用されます。項6.4.4. 「ENUM 型」 を参照してください。

SET オブジェクトのサイズは異なるセットメンバーの数によって決定します。もしセットサイズが N なら、オブジェクトは 1、2、3、4、または 8 バイトに丸められた (N+7)/8 バイトをコピーします。SET は最高 64 メンバーを持つことができます。項6.4.5. 「SET 型」 を参照してください。