ディスク上のテーブルデータのストレージ要件は、複数の要因によって異なります。別々のストレージエンジンは異なる方法でデータ型を表し、ローデータを格納します。カラムか行全体のどちらかでテーブルデータを圧縮できますが、テーブルまたはカラムのストレージ要件の計算が複雑になります。
ディスク上のストレージレイアウトが違っていても、テーブル行に関する情報を通信および交換する内部 MySQL API は、すべてのストレージエンジンにわたって適用される一貫したデータ構造を使用します。
このセクションでは、データ型の固定サイズ表現を使用するストレージエンジンの内部形式およびサイズを含め、MySQL がサポートするデータ型ごとのストレージ要件に関するガイドラインおよび情報について説明します。情報はカテゴリまたはストレージエンジンごとに示します。
テーブルの内部表現の最大行サイズは 65,535 バイトであり、ストレージエンジンがこれ以上のサイズの行をサポートできる場合でもこのサイズになります。BLOB
または TEXT
カラムはこのサイズに 9 から 12 バイトしか関与しないので、これらのカラムはこのサイズに含まれません。BLOB
および TEXT
データについての情報は、行バッファーとは異なるメモリー領域に内部的に格納されます。それぞれのストレージエンジンは、対応する型の処理に使用する方法に従って異なる方法で、このデータの割り当ておよびストレージを扱います。詳細は、第15章「代替ストレージエンジン」およびセクションD.10.4「テーブルカラム数と行サイズの制限」を参照してください。
InnoDB テーブルのストレージ要件
InnoDB
テーブルのストレージ要件の詳細は、セクション14.2.13.7「物理的な行構造」を参照してください。
NDBCLUSTER テーブルのストレージ要件
NDB
テーブルは、4 バイトアライメントを使用します。すべての NDB
データストレージは、4 バイトの倍数で行われます。したがって、通常であれば 15 バイトを使用するカラム値は、NDB
テーブルでは 16 バイトを必要とします。たとえば、NDB
テーブルでは、TINYINT
、SMALLINT
、MEDIUMINT
、および INTEGER
(INT
) カラム型はそれぞれ、アライメント係数により、レコードあたり 4 バイトのストレージが必要になります。
各 BIT(
カラムは M
)M
ビットのストレージ領域を使用します。各 BIT
カラムは 4 バイトアライメントが行われていませんが、NDB
は、BIT
カラムに必要な最初の 1 から 32 ビットに行あたり 4 バイト (32 ビット) を、33 から 64 ビットに別の 4 ビットを、というように予約します。
NULL
自体はストレージ領域を必要としませんが、NDB
は、テーブル定義に NULL
として定義されたカラム (最大 32 の NULL
カラム) が含まれる場合、行あたり 4 バイトを予約します。(MySQL Cluster テーブルが 32 以上の NULL
カラムから 64 の NULL
カラムで定義されている場合、行あたり 8 バイトが予約されます。)
NDB
ストレージエンジンを使用するすべてのテーブルで主キーが必要になります。主キーを定義していない場合、「非表示」の主キーが NDB
によって作成されます。この非表示の主キーはテーブルレコードあたり 31 から 35 バイトを消費します。
ndb_size.pl Perl スクリプトを使用して、NDB
ストレージ要件を評価します。これは、(MySQL Cluster ではなく) 現在の MySQL データベースに接続し、そのデータベースが NDB
ストレージエンジンを使用した場合にどれだけの領域を必要とするかについてレポート作成します。詳細は、セクション18.4.25「ndb_size.pl — NDBCLUSTER サイズ要件エスティメータ」を参照してください。
数値型のストレージ要件
データ型 | 必要なストレージ |
---|---|
TINYINT |
1 バイト |
SMALLINT |
2 バイト |
MEDIUMINT |
3 バイト |
INT 、INTEGER
|
4 バイト |
BIGINT |
8 バイト |
FLOAT( |
0 <= p <= 24 の場合は 4 バイト、25 <= p <= 53 の場合は 8 バイト |
FLOAT |
4 バイト |
DOUBLE [PRECISION] 、REAL
|
8 バイト |
DECIMAL( 、NUMERIC(
|
変動; 次の説明を参照 |
BIT( |
約 (M +7)/8 バイト |
DECIMAL
(および NUMERIC
) カラムの値は、9 桁の 10 進数 (10 進法) を 4 バイトにパックするバイナリ形式を使用して表現されます。各値の整数部と小数部のストレージは、個別に決定されます。9 桁の倍ごとに 4 バイトが必要であり、「余りの」桁には 4 バイトのうちの一部が必要です。余りの桁に必要なストレージ要件を次の表に示します。
余りの桁 | バイト数 |
---|---|
0 | 0 |
1 | 1 |
2 | 1 |
3 | 2 |
4 | 2 |
5 | 3 |
6 | 3 |
7 | 4 |
8 | 4 |
日付と時間型のストレージ要件
TIME
、DATETIME
、および TIMESTAMP
カラムの場合、MySQL 5.6.4 よりも前に作成されたテーブルに必要なストレージは、5.6.4 以降で作成されたテーブルとは異なります。これは、5.6.4 で、0 から 3 バイトを必要とする小数部をこれらの型が持つことを許可するように変更されたためです。
データ型 | MySQL 5.6.4 より前で必要なストレージ | MySQL 5.6.4 以降で必要なストレージ |
---|---|---|
YEAR |
1 バイト | 1 バイト |
DATE |
3 バイト | 3 バイト |
TIME |
3 バイト | 3 バイト + 小数秒ストレージ |
DATETIME |
8 バイト | 5 バイト + 小数秒ストレージ |
TIMESTAMP |
4 バイト | 4 バイト + 小数秒ストレージ |
MySQL 5.6.4 以降、YEAR
および DATE
のストレージは変更ありません。ただし、TIME
、DATETIME
、および TIMESTAMP
は異なって表現されます。DATETIME
はより効率的にパックされ、非小数部に必要なバイト数は 8 バイトではなく 5 バイトであり、3 つの部分すべてに、格納値の小数秒精度に応じて 0 から 3 バイトが必要な小数部があります。
小数秒精度 | 必要なストレージ |
---|---|
0 | 0 バイト |
1、2 | 1 バイト |
3、4 | 2 バイト |
5、6 | 3 バイト |
たとえば、TIME(0)
、TIME(2)
、TIME(4)
、および TIME(6)
はそれぞれ 3、4、5、6 バイトを使用します。TIME
と TIME(0)
は同等で、必要なストレージは同じです。
時間値の内部表現の詳細は、「MySQL Internals: Important Algorithms and Structures」を参照してください。
文字列型のストレージ要件
次の表では、M
は宣言されたカラムの長さを、非バイナリ文字列型の場合は文字数で、バイナリ文字列型の場合はバイト数で表します。L
は指定された文字列値の実際の長さをバイト数で表します。
データ型 | 必要なストレージ |
---|---|
CHAR( |
M × w バイト、0 <= 255、ここで w は、文字セット内の最大長の文字に必要なバイト数です。InnoDB テーブルの CHAR データ型のストレージ要件の詳細は、セクション14.2.13.7「物理的な行構造」を参照してください。 |
BINARY( |
M バイト、0 <= 255 |
VARCHAR( 、VARBINARY(
|
カラム値が 0 から 255 バイトを必要とする場合は、L + 1 バイト、値が 255 バイト以上を必要とする可能性のある場合は、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(' |
列挙値の数 (最大 65,535 個の値) により 1 または 2 バイト |
SET(' |
セットメンバーの数 (最大 64 メンバー) により、1、2、3、4、または 8 バイト |
可変長の文字列型は、長さプリフィクスが付いたデータを使用して格納されます。長さプリフィクスにはデータ型に応じて 1 から 4 バイトが必要で、プリフィクスの値は L
(文字列のバイト長) です。たとえば、MEDIUMTEXT
値のストレージには、値を格納するための L
バイトに加えて、値の長さを格納するための 3 バイトが必要です。
特定の CHAR
、VARCHAR
、または TEXT
カラム値の格納に使用されるバイト数を計算するには、そのカラムに使用される文字セットと、値にマルチバイト文字が含まれるかどうかを考慮する必要があります。特に、utf8
(または utf8mb4
) Unicode 文字セットを使用する場合、すべての文字セットが同じバイト数を使用するわけではなく、文字あたり最大 3 (4) バイトを必要とするわけではないことに注意する必要があります。utf8
または utf8mb4
文字の異なるカテゴリに使用されるストレージの詳細は、セクション10.1.10「Unicode のサポート」を参照してください。
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 文字になるように宣言できます。セクションD.10.4「テーブルカラム数と行サイズの制限」を参照してください。
NDB
ストレージエンジンは可変幅カラムをサポートします。これは、MySQL Cluster テーブル内の VARCHAR
カラムは、このような値に対して 4 バイトアライメントが行われる点を除き、ほかのストレージエンジンと同じ容量のストレージを必要とするということを意味します。したがって、latin1
文字セットを使用して VARCHAR(50)
カラムに格納された文字列 'abcd'
は、(MyISAM
テーブル内の同じカラム値に対する 5 バイトではなく) 8 バイトを必要とします。
TEXT
と BLOB
カラムは、NDB
ストレージエンジンでは異なって実装されます。ここでは、TEXT
カラム内の各行は 2 つの別々の部分から構成されています。そのうちの 1 つは固定サイズ (256 バイト) で、実際に元のテーブルに格納されます。もう 1 つは 256 バイトを超えるデータで構成され、非表示のテーブルに格納されます。2 番目のテーブルの行の長さは常に 2,000 バイトです。これは、size
<= 256 (ここで size
は行のサイズを表します) の場合、TEXT
カラムのサイズが 256 であり、それ以外の場合はサイズが 256 + size
+ (2000 − (size
− 256) % 2000) であることを意味します。
ENUM
オブジェクトのサイズは異なる列挙値の数によって決まります。最大 255 の値を持つ列挙に 1 バイトが使用されます。256 から 65,535 の値を持つ列挙に 2 バイトが使用されます。セクション11.4.4「ENUM 型」を参照してください。
SET
オブジェクトのサイズは異なるセットメンバーの数によって決まります。セットサイズが N
である場合、オブジェクトは 1、2、3、4、または 8 バイトに丸められた (
バイトを占めます。N
+7)/8SET
は最大 64 メンバーを持つことができます。セクション11.4.5「SET 型」を参照してください。