ディスク上のテーブルデータのストレージ要件は、複数の要因によって異なります。 別々のストレージエンジンは異なる方法でデータ型を表し、ローデータを格納します。 カラムか行全体のどちらかでテーブルデータを圧縮できますが、テーブルまたはカラムのストレージ要件の計算が複雑になります。
ディスク上のストレージレイアウトが違っていても、テーブル行に関する情報を通信および交換する内部 MySQL API は、すべてのストレージエンジンにわたって適用される一貫したデータ構造を使用します。
このセクションでは、データ型の固定サイズ表現を使用するストレージエンジンの内部形式およびサイズを含め、MySQL がサポートするデータ型ごとのストレージ要件に関するガイドラインおよび情報について説明します。 情報はカテゴリまたはストレージエンジンごとに示します。
テーブルの内部表現の最大行サイズは 65,535 バイトであり、ストレージエンジンがこれ以上のサイズの行をサポートできる場合でもこのサイズになります。 BLOB または TEXT カラムはこのサイズに 9 から 12 バイトしか関与しないので、これらのカラムはこのサイズに含まれません。 BLOB および TEXT データについての情報は、行バッファーとは異なるメモリー領域に内部的に格納されます。 それぞれのストレージエンジンは、対応する型の処理に使用する方法に従って異なる方法で、このデータの割り当ておよびストレージを扱います。 詳細は、第16章「代替ストレージエンジン」およびセクション8.4.7「テーブルカラム数と行サイズの制限」を参照してください。
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 自体には記憶域領域は必要ありませんが、テーブル定義に NULL を許可するカラムが含まれている場合、NDB は行ごとに最大 32 の NULL カラムを予約します。 (「NDB Cluster」テーブルに 32 を超える NULL カラムが定義されている場合、行当たり 8 バイトが予約されます。)
NDB ストレージエンジンを使用するすべてのテーブルで主キーが必要になります。主キーを定義していない場合、「非表示」の主キーが NDB によって作成されます。 この非表示の主キーはテーブルレコードあたり 31 から 35 バイトを消費します。
ndb_size.pl Perl スクリプトを使用して、NDB ストレージ要件を評価します。 現在の MySQL (NDB Cluster ではない) データベースに接続し、データベースが NDB ストレージエンジンを使用した場合に必要となる領域の量に関するレポートを作成します。 詳細は、セクション23.4.28「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( |
InnoDB 行形式のコンパクトファミリは、可変長文字セットの記憶域を最適化します。 COMPACT 行形式の格納特性を参照してください。 それ以外の場合は、M× w バイト、<= 255。ここで、w は、文字セット内の最大長文字に必要なバイト数です。 |
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 Unicode 文字セットを使用する場合は、すべての文字が同じバイト数を使用するわけではないことに注意する必要があります。utf8mb3 および utf8mb4 の文字セットには、それぞれ最大 3 バイトと 4 バイトが必要です。 様々なカテゴリの utf8mb3 または utf8mb4 文字に使用される記憶域の内訳は、セクション10.9「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 カラムの場合、文字の有効な最大数は少なくなります。 たとえば、utf8mb4 文字には文字ごとに最大 4 バイトが必要な場合があるため、utf8mb4 文字セットを使用する VARCHAR カラムは 16,383 文字まで宣言できます。 セクション8.4.7「テーブルカラム数と行サイズの制限」を参照してください。
InnoDB では、768 バイト以上の固定長フィールドが可変長フィールドとしてエンコードされ、オフページに格納できます。 たとえば、utf8mb4 と同様に、文字セットの最大バイト長が 3 より大きい場合、CHAR(255) カラムは 768 バイトを超えることがあります。
NDB ストレージエンジンは可変幅カラムをサポートします。 つまり、「NDB Cluster」テーブルの VARCHAR カラムには、ほかのストレージエンジンと同じ量のストレージが必要ですが、このような値が 4 バイトに整列されている点が異なります。 したがって、latin1 文字セットを使用して VARCHAR(50) カラムに格納された文字列 'abcd' は、(MyISAM テーブル内の同じカラム値に対する 5 バイトではなく) 8 バイトを必要とします。
NDB では、TEXT カラムと BLOB カラムは異なる方法で実装されます。TEXT カラムの各行は、2 つの部分で構成されます。 そのうちの 1 つは固定サイズ (256 バイト) で、実際に元のテーブルに格納されます。 もう 1 つは 256 バイトを超えるデータで構成され、非表示のテーブルに格納されます。 2 番目のテーブルの行の長さは常に 2000 バイトです。 これは、size <= 256 (size は行のサイズを表す) の場合、TEXT カラムのサイズが 256 であることを意味します。それ以外の場合、サイズは 256 + size + (2000 × (size − 256) % 2000) です。
ENUM オブジェクトのサイズは異なる列挙値の数によって決まります。 最大 255 の値を持つ列挙に 1 バイトが使用されます。 256 から 65,535 の値を持つ列挙に 2 バイトが使用されます。 セクション11.3.5「ENUM 型」を参照してください。
SET オブジェクトのサイズは異なるセットメンバーの数によって決まります。 セットサイズが N である場合、オブジェクトは 1、2、3、4、または 8 バイトに丸められた ( バイトを占めます。 N+7)/8SET は最大 64 メンバーを持つことができます。 セクション11.3.6「SET 型」を参照してください。
MySQL では、SRID の後に WKB 表現の値が続くことを示す 4 バイトを使用してジオメトリ値が格納されます。 LENGTH() 関数は、値の格納に必要な領域をバイト単位で返します。
WKB および空間値の内部記憶域形式の詳細は、セクション11.4.3「サポートされる空間データ形式」 を参照してください。
一般に、JSON カラムの記憶域要件は、LONGBLOB または LONGTEXT カラムの場合とほぼ同じです。つまり、JSON ドキュメントによって消費される領域は、これらのいずれかの型のカラムに格納されるドキュメント文字列表現の場合とほぼ同じです。 ただし、JSON ドキュメントに格納されている個々の値のメタデータやディクショナリなど、バイナリエンコーディングによるオーバーヘッドがあります。 たとえば、JSON ドキュメントに格納されている文字列には、文字列の長さおよび格納されているオブジェクトまたは配列のサイズに応じて、4 から 10 バイトの追加記憶域が必要です。
また、MySQL では、max_allowed_packet の値より大きくできないように、JSON カラムに格納される JSON ドキュメントのサイズに制限が課されます。