MySQL 学習シリーズ 3: データ型

MYSQL の BLOB データ型

BLOB は、可変量のデータを格納するために使用されるバイナリ ラージ オブジェクトです。 BLOB には、TinyBlob、Blob、MediumBlob、LongBlob の 4 つのタイプがあります。これらのタイプの唯一の違いは、保存されるファイルの最大サイズです。

MySQL の 4 つの BLOB タイプの型サイズ (単位: バイト)

TinyBlob 最大 255

Blob 最大 65K

MediumBlob 最大 16M

LongBlob 最大 4G

BLOB 列にはバイナリ文字列 (バイト文字列) が格納されます。店非バイナリ文字列（文字列）。

BLOB列には文字セットがなく、ソートと比較は列値バイトの数値に基づいて行われます; TEXT列には文字セットがあり、値は文字セットに基づいてソートおよび比較されます

BLOBはバイナリ文字列、TEXT は非バイナリ文字列で、どちらも大量の情報を格納できます。 BLOB には主に画像や音声情報などが保存されますが、TEXT にはテキスト ファイルのみを保存できます。

SQLSERVER

SQLSERVER には BLOB データ型はなく、ラージ オブジェクト データ型 (BLOB) のみがあります:

text、ntext、image、nvarchar(max)、varchar(max)、varbinary(max) および xml データ型

これらのデータ型は、LOB 型データ ページ




列型

11.1.1 数値型の概要に格納されます。

以下は数値列タイプの概要です。詳細については、「数値型」を参照してください。列の記憶域要件については、11.5項「列タイプの記憶域要件」を参照してください。

Mは最大表示幅を示します。最大有効表示幅は 255 です。 11.2項「数値型」で説明されているように、表示幅は、記憶域サイズや型に含まれる値の範囲とは関係がありません。

数値カラムに ZEROFILL を指定すると、MySQL は自動的に UNSIGNED 属性をカラムに追加します。

SERIAL は、BIGINT UNSIGNED NOT NULL AUTO_INCREMENT UNIQUE のエイリアスです。

整数列定義では、SERIAL DEFAULT VALUE は NOT NULL AUTO_INCREMENT UNIQUE のエイリアスです。

警告: 整数値 (そのうちの 1 つは UNSIGNED 型) の間にマイナス記号を使用すると、結果は符号なしになることは明らかです。 「キャスト関数と演算子」を参照してください。

· BIT[(M)]

ビットフィールドタイプ。 M は値ごとのビット数を表し、範囲は 1 ～ 64 です。 M を省略した場合、デフォルトは 1 になります。

· TINYINT[(M)] [UNSIGNED] [ZEROFILL]

非常に小さい整数。符号付きの範囲は -128 ～ 127 です。符号なしの範囲は 0 ～ 255 です。

· BOOL、BOOLEAN

は TINYINT(1) の同義語です。値 0 は false とみなされます。ゼロ以外の値は true とみなされます。

将来的には、標準 SQL に従って完全なブール型処理が導入される予定です。

· SMALLINT[(M)] [UNSIGNED] [ZEROFILL]

小さい整数。符号付きの範囲は -32768 ～ 32767 です。符号なしの範囲は 0 ～ 65535 です。

· MEDIUMINT[(M)] [UNSIGNED] [ZEROFILL]

中サイズの整数。符号付きの範囲は -8388608 ～ 8388607 です。符号なしの範囲は 0 ～ 16777215 です。

· INT[(M)] [UNSIGNED] [ZEROFILL]

通常サイズの整数。符号付きの範囲は -2147483648 ～ 2147483647 です。符号なしの範囲は 0 ～ 4294967295 です。

· INTEGER[(M)] [UNSIGNED] [ZEROFILL]

これは INT の同義語です。

· BIGINT[(M)] [UNSIGNED] [ZEROFILL]

多倍長整数。符号付きの範囲は -9223372036854775808 ～ 9223372036854775807 です。符号なしの範囲は 0 ～ 18446744073709551615 です。

BIGINT 列について次の点を明確にする必要があります:

o すべてのアルゴリズムで符号付き BIGINT または DOUBLE 値を使用するため、ビット関数を除き、9223372036854775807 (63 ビット) より大きい符号なし整数は使用しないでください。これを行うと、BIGINT 値を DOUBLE に変換する際の丸め誤差により、結果の最後の数桁が間違っている可能性があります。

MySQL は次の状況で BIGINT を処理できます:

§ 整数を使用して大きな符号なしの値を BIGINT カラムに格納する場合。

§ MIN(col_name) または MAX(col_name) で、col_name は BIGINT 列を指します。

§ 演算子 (+、-、​​ など) を使用し、両方のオペランドが整数である場合。

o 文字列を使用して BIGINT 列に厳密な整数値を保持することは常に可能です。この場合、MySQL は文字列から数値への変換を実行しますが、その間に倍精度表現は存在しません。

o -、+、および * 演算子は、両方のオペランドが整数値の場合に BIGINT アルゴリズムを使用します。これは、2 つの大きな整数を乗算すると (または整数を返す関数で乗算すると)、結果が 9223372036854775807 より大きい場合に予期しない結果が得られることを示しています。

· FLOAT[(M,D)] [UNSIGNED] [ZEROFILL]

小さい (単精度) 浮動小数点数。許可される値は、-3.402823466E+38 ～ -1.175494351E-38、0、および 1.175494351E-38 ～ 3.402823466E+38 です。これらは、IEEE 標準に基づいた理論上の制限です。実際の範囲は、ハードウェアまたはオペレーティング システムによってはわずかに小さくなる場合があります。

Mは小数点以下の桁数、Dは小数点以下の桁数です。 M と D を省略した場合、値はハードウェアで許可されている制限に従って保存されます。単精度浮動小数点数は、小数点以下約 7 桁まで正確です。

UNSIGNED が指定されている場合、負の値は許可されません。

MySQL ではすべての計算が倍精度で行われるため、浮動小数点数を使用すると予期しない問題が発生する可能性があります。セクションA.5.7「一致しない行の問題の解決」を参照してください。

・DOUBLE[(M,D)] [UNSIGNED] [ZEROFILL]

通常サイズ(倍精度)の浮動小数点数。許可される値は、-1.7976931348623157E+308 ～ -2.2250738585072014E-308、0 および 2.2250738585072014E-308 ～ 1.7976931348623157E+308 です。これらは、IEEE 標準に基づいた理論上の制限です。実際の範囲は、ハードウェアまたはオペレーティング システムによってはわずかに小さくなる場合があります。

Mは小数点以下の合計桁数、Dは小数点以下の桁数です。 M と D を省略した場合、値はハードウェアで許可されている制限に従って保存されます。倍精度浮動小数点数は、小数点以下約 15 桁まで正確です。

UNSIGNED が指定されている場合、負の値は許可されません。

・DOUBLE PRECISION[(M,D)] [UNSIGNED] [ZEROFILL]、REAL[(M,D)]
[UNSIGNED] [ZEROFILL]

はDOUBLEの同義語です。ただし、SQL サーバー モードに REAL_AS_FLOAT オプションが含まれている場合、REAL は DOUBLE のシノニムではなく、FLOAT のシノニムになります。

· FLOAT(p) [UNSIGNED] [ZEROFILL]

浮動小数点数。 p は精度 (ビット単位で表現) を表しますが、MySQL はこの値を結果カラムのデータ型が FLOAT か DOUBLE かを決定するためにのみ使用します。 p が 0 ～ 24 の場合、データ型は M または D 値のない FLOAT になります。 p が 25 ～ 53 の場合、データ型は M または D 値なしの DOUBLE になります。結果の列範囲は、このセクションで前述した単精度 FLOAT または倍精度 DOUBLE データ型と同じになります。

FLOAT(p) 構文は ODBC と互換性があります。

· DECIMAL[(M[,D])] [UNSIGNED] [ZEROFILL]

圧縮された「厳密な」固定小数点数。 M は小数点以下の合計桁数 (精度)、D は小数点以下の桁数 (スケール) です。小数点と「-」記号 (負の数の場合) は M には含まれません。 D が 0 の場合、値には小数点や小数部はありません。 DECIMAL 整数の最大桁数 (M) は 65 です。サポートされる 10 進数 (D) の最大数は 30 です。 D が省略された場合、
のデフォルトは 0 です。 M を省略した場合、デフォルトは 10 です。

UNSIGNED が指定されている場合、負の値は許可されません。

すべての DECIMAL 列 (+、-、​​、/) の基本的な計算は 65 ビット精度で行われます。

· DEC[(M[,D])] [符号なし] [ゼロフィル]、数値[(M[,D])]
[符号なし] [ゼロフィル]、固定[(M[,D])] [符号なし] [ZEROFILL]

は DECIMAL の同義語です。 FIXED シノニムは、他のサーバーとの互換性のために適用されます。

11.1.2. 日付と時刻の型の概要

このセクションでは、一時列の型について包括的に説明します。詳細については、「日付と時刻のタイプ」を参照してください。列の記憶域要件については、11.5項「列タイプの記憶域要件」を参照してください。

·DATE

日付。サポートされている範囲は「1000-01-01」から「9999-12-31」です。 MySQL は DATE 値を「YYYY-MM-DD」形式で表示しますが、文字列または数値を使用して DATE カラムに値を割り当てることができます。

·DATETIME

日付と時刻の組み合わせ。サポートされている範囲は「1000-01-01 00:00:00」から「9999-12-31 23:59:59」です。 MySQL は DATETIME 値を「YYYY-MM-DD HH:MM:SS」形式で表示しますが、文字列または数値を使用して DATETIME カラムに値を割り当てることができます。

· TIMESTAMP[(M)]

タイムスタンプ。範囲は「1970-01-01 00:00:00」から 2037 までです。

TIMESTAMP 列は、INSERT または UPDATE 操作中に日付と時刻を記録するために使用されます。値を割り当てない場合、テーブルの最初の TIMESTAMP 列は、最新の操作の日付と時刻に自動的に設定されます。 NULL 値を割り当てて、TIMESTAMP 列を現在の日付と時刻に設定することもできます。

TIMESTAMP 値は「YYYY-MM-DD HH:MM:SS」形式の文字列として返され、表示幅は 19 文字に固定されます。数値を取得したい場合は、TIMESTAMP列に+0を加えます。

注: MySQL 4.1 より前に使用されていた TIMESTAMP 形式は MySQL 5.1 ではサポートされていません。古い形式については、MySQL 4.1 リファレンス マニュアルを参照してください。

・時間

時間。範囲は「-838:59:59」から「838:59:59」です。 MySQL は TIME 値を「HH:MM:SS」形式で表示しますが、文字列または数値を使用して TIME カラムに値を割り当てることができます。

· YEAR[(2|4)]

2 桁または 4 桁の形式の年。デフォルトは 4 桁の形式です。 4 桁の形式では、許可される値は 1901 ～ 2155 および 0000 です。 2 桁の形式では、許可される値は 70 ～ 69 で、1970 年から 2069 年までの年を表します。 MySQL は YEAR 値を YYYY 形式で表示しますが、文字列または数値を使用して YEAR カラムに値を割り当てることができます。

11.1.3. 文字列型の概要

このセクションでは、文字列列の型について包括的に説明します。詳細については、「文字列型」を参照してください。列の記憶域要件については、11.5項「列タイプの記憶域要件」を参照してください。

場合によっては、MySQL は文字列カラムを CREATE TABLE または ALTER TABLE ステートメントで指定された型とは異なる型に変更することがあります。セクション13.1.5.1「サイレントカラム仕様の変更」を参照してください。

MySQL 5.1 の文字列データ型には、MySQL 4.1 より前のバージョンでは利用できなかったいくつかの機能が含まれています:

· 多くの文字列データ型の列定義には、文字セットを指定する CHARACTER SET 属性を含めることができ、照合順序も含めることができます。ルール。 (CHARSET は CHARACTER SET の同義語です)。これらのプロパティは、CHAR、VARCHAR、TEXT 型、ENUM、SET に適用されます。例:

このテーブル定義は、utf8 文字セットとその文字セットのデフォルト照合順序を持つ c1 という名前の列と、latin1 文字セットとその文字セットのデフォルト照合順序を持つ c2 という名前の列を作成します。バイナリ校正ルール。バイナリ照合ルールでは大文字と小文字が区別されません。

· MySQL 5.1 は、文字カラム定義の長さの指定を文字単位で解釈します。 (MySQL の以前のバージョンの中には、長さをバイト単位で解釈するものもあります)。

· CHAR、VARCHAR、TEXT 型の場合、BINARY 属性は列文字セットの照合規則を列に割り当てることができます。

· 文字列は、その列に割り当てられた文字セットに基づいて並べ替えおよび比較されます。以前のバージョンでは、並べ替えと比較はサーバーの文字セットの照合規則に基づいていました。 CHAR 列と VARCHAR 列の場合、BINARY 属性を使用して列を宣言すると、並べ替え規則と照合規則で字句順序ではなく現在の文字コード値が使用されるようになります。

MySQL 5.1 での文字セットのサポートについては、第 10 章: 文字セットのサポートを参照してください。

· [NATIONAL] CHAR(M) [BINARY| ASCII | UNICODE]

保存時に指定された長さになるように右側にスペースが埋め込まれる固定長の文字列。 M は列の長さを表します。 M の範囲は 0 ～ 255 文字です。

注: CHAR 値を取得する場合、末尾のスペースは削除されます。

CHAR の長さを 255 より大きく設定したい場合、実行された CREATE TABLE または ALTER TABLE ステートメントは失敗し、エラーが表示されます:

CHARはCHARACTERの略称です。 NATIONAL CHAR (または同等の短い形式の NCHAR) は、CHAR 列がデフォルトの文字セットを使用することを定義する標準 SQL 方法です。これは MySQL のデフォルト値です。

BINARY 属性は、指定された列文字セットのバイナリ照合規則の省略形です。並べ替えと比較は数値文字値に基づいて行われます。

列型 CHAR BYTE は、CHAR BINARY の別名です。これは互換性を確保するためです。

CHARにはASCII属性を指定できます。 latin1 文字セットを割り当てます。

CHARにはUNICODE属性が指定可能です。 ucs2 文字セットを割り当てます。

MySQL では、CHAR(0) 型の列を作成できます。これは主に、列が必要だが実際には値を使用しない古いバージョンのアプリケーションとの互換性を保つためです。 2 つの値のみを取ることができる列が必要な場合にも適しています。NOT NULL として定義されていない CHAR(0) 列は 1 ビットのみを使用し、値 NULL と "(空の文字列) のみを取ることができます。

· CHAR

これは CHAR(1) の同義語です

· [NATIONAL] VARCHAR(M) [BINARY]

M の範囲は 0 ～ 65,535 (VARCHAR の実際の最大長。最長の行と使用される文字セット。有効な最大長は 65,532 バイトです)

注: MySQL 5.1 は、VARCHAR 値から末尾のスペースを削除しません。
VARCHAR は文字 VARYING です。
BINARY 属性は、指定された列のバイナリ照合ルールです。並べ替えと比較は、1 バイトまたは 2 バイトの長さの接頭辞とデータを使用して保存されます。 255、長さのプレフィックスは 2 バイトです

・BINARY(M)

BINARY 型は CHAR 型に似ていますが、非バイナリ文字列の代わりにバイナリバイト文字列を保持します

・VARBINARY(M)

VARBINARY 型は VARCHAR 型に似ていますが、非バイナリ文字列ではなくバイナリ バイト文字列を保持します。

· TINYBLOB

最大長 255 (28–1) バイトの BLOB 列。最大長は 255 (28–1) 文字です。

· BLOB[(M)]

最大長が 65,535 (216–1) 文字の BLOB 列を指定できます。指定された場合は、MySQL です。 M バイトを保持できる最小の BLOB タイプとして列を作成します

· TEXT[(M)]

最大長は 65,535(216–1) の文字の TEXT 列を指定できます。オプションの長さは M です。その後、MySQL は M 文字を保持できる最小の TEXT 型としてカラムを作成します。

· MEDIUMBLOB

最大長は 16,777,215 (224–1) バイトです。 · MEDIUMTEXT

TEXT 列の最大長は 16,777,215 (224–1) 文字です。

· LONGBLOB

LONGBLOB 列の最大長は 4,294,967,295 または 4GB (232–1) 文字です。構成された最大パケット サイズとクライアント/サーバー プロトコルで使用可能なメモリによって異なります。

· LONGTEXT

LONGTEXT 列の最大長は 4,294,967,295 または 4GB (232–1) 文字です。クライアント/サーバー プロトコルで設定された最大パケット サイズと利用可能なメモリ。

· ENUM(‘value1‘, ‘value2‘,…)

列挙型。値列「value1」、「value2」、...、NULL、または特別な「エラー値」から選択された値を 1 つだけ持つことができる文字列。ENUM 列には、最大 65,535 個の個別の値を含めることができます。内部的には整数表現が使用されます。

· SET('value1','value2',…)

文字列オブジェクトは 0 個以上の値を持つことができ、各値は列の値 'value1'、'value2' から取得する必要があります。 , ...SET 列は最大 64 個のメンバーを持つことができます。 SET 値は内部的に整数として表されます。 NUMERIC)、および近似数値データ型 (FLOAT、REAL、および DOUBLE PRECISION) キーワード INT は INTEGER の同義語であり、キーワード DEC は DECIMAL の同義語です。BIT データ型はビット フィールド値を格納し、MyISAM をサポートします。 MEMORY、InnoDB、BDB テーブル

SQL 標準の拡張として、MySQL は整数型 TINYINT、MEDIUMINT、および BIGINT もサポートしています。次の表は、各整数型に必要なストレージと範囲を示しています。 value 最大値

(符号付き/符号なし) (符号あり/符号なし)

TINYINT 1 -128 127

0 255

SMALLINT 2 -32768 327 67

0 65535

MEDIUMINT 3 - 8388608 8388607

0 16777215

INT 4 -2147483648 2147483647

0 4294967295

BIGINT 8 -922337 2036854775808 9223372036854775807

0 184467 44073709551615

MySQL は、type キーワードに続く括弧内の整数値の表示幅を指定するオプションもサポートしています (例: INT(4))。オプションの表示幅指定は、表示幅が指定された列幅より小さい場合に、左から幅を埋めるために使用されます。

表示幅は、列内に保存できる値の範囲を制限したり、列の指定された幅を超える値の表示を制限したりしません。

オプションの拡張属性 ZEROFILL と組み合わせて使用​​すると、デフォルトの補足スペースがゼロに置き換えられます。たとえば、INT(5) ZEROFILL として宣言された列の場合、値 4 は 00004 として取得されます。表示された幅を超える値を整数列に格納すると、MySQL は複雑な結合用の一時テーブルを生成するときに問題が発生することに注意してください。このような場合、MySQL はデータが元の列幅に適合すると判断するためです。

すべての整数型は、オプションの (非標準) 属性 UNSIGNED を持つことができます。符号なしの値は、列に負でない数値のみを許可し、その列でより大きな上限の数値範囲が必要な場合に使用できます。

浮動小数点型と固定小数点型も UNSIGNED にすることができます。同じ数値タイプの場合、このプロパティにより、負の値が列に保存されなくなります。ただし、整数型とは異なり、列値の上限は変わりません。

数値カラムに ZEROFILL を指定すると、MySQL は自動的に UNSIGNED 属性をカラムに追加します。

MySQL では、浮動小数点カラム型の場合、単精度値は 4 バイト、倍精度値は 8 バイトを使用します。

FLOAT 型は、近似的な数値データ型を表すために使用されます。 SQL 標準では、キーワード FLOAT に続く括弧内で精度をビット単位で指定するオプションが許可されています (ただし、指数範囲は指定できません)。 MySQL は、ストレージ サイズを決定するためにのみ使用されるオプションの精度仕様もサポートしています。 0 ～ 23 の精度は、FLOAT 列の 4 バイトの単精度に対応します。 24 ～ 53 の精度は、DOUBLE 列の 8 バイトの倍精度に対応します。

MySQL では、FLOAT(M,D)、REAL(M,D)、DOUBLE
PRECISION(M,D) などの非標準構文の使用が許可されています。ここで、「(M,D)」とは、小数点以下D桁の合計M桁の整数を表示する値を意味します。たとえば、FLOAT(7,4) として定義された列は、-999.9999 と表示される可能性があります。 MySQL は保存時に値を四捨五入するため、FLOAT(7,4) カラムに 999.00009 を挿入すると、おおよその結果は 999.0001 になります。

MySQL は、DOUBLE を DOUBLE PRECISION (非標準拡張) の同義語として扱います。また、MySQL は、SQL サーバー モードに REAL_AS_FLOAT オプションが含まれていない限り、REAL を DOUBLE PRECISION (非標準拡張) の同義語として扱います。

最大限の移植性を確保するには、近似数値データ値の格納を必要とするコードは、精度や桁数を指定せずに FLOAT または DOUBLE PRECISION を使用する必要があります。

DECIMAL 型と NUMERIC 型は、MySQL では同じ型として扱われます。これらは、通貨データなど、正確な精度が必要な値を保持するために使用されます。このタイプの列を宣言する場合、次のように精度と位取りを指定できます (通常はそうします)。

この例では、5 が精度、2 がスケールです。精度は値を保存できる桁数を示し、スケールは小数点以下の桁数を保存できます。

MySQL 5.1 で DECIMAL 値と NUMERIC 値をバイナリ形式で保存します。

標準 SQL では、給与列に 5 桁の整数と小数点以下 2 桁の任意の値を格納できる必要があります。したがって、この場合、給与列に保存できる値の範囲は、-999.99 ～ 999.99 となります。

標準 SQL では、構文 DECIMAL(M) は DECIMAL(M,0) と同等です。同様に、構文 DECIMAL は DECIMAL(M,0) と同等であり、M の値は計算によって決定できます。 DECIMAL および NUMERIC データ型の変数形式は MySQL
5.1 でサポートされています。 M のデフォルト値は 10 です。

DECIMAL または NUMERIC の最大桁数は 65 ですが、特定の DECIMAL または NUMERIC 列の実際の範囲は、特定の列の精度または位取りによって制限されます。このような列に、指定されたスケールで許可されているよりも多くの小数点以下の桁数を含む値が割り当てられている場合、値はそのスケールに変換されます。 (具体的な操作はオペレーティング システムによって異なりますが、通常、結果は許容される桁数に切り捨てられます)。

BIT データ型は、ビットフィールド値を保存するために使用できます。 BIT(M) タイプでは、M ビット値を保存できます。 M の範囲は 1 ～ 64 です。

ビット値を指定するには、b'value' シンボルを使用できます。 value は、0 と 1 で書かれたバイナリ値です。たとえば、b'111' と b'100000000' はそれぞれ 7 と 128 を表します。 「ビットフィールド値」を参照してください。

BIT(M)列に割り当てられた値の長さがMビット未満の場合、値の左側を0で埋めます。たとえば、値 b'101' を BIT(6) 列に割り当てると、b'000101' を割り当てるのと同じ効果が得られます。

数値カラムにそのカラムの許容範囲を超える値を保存したい場合、MySQL の動作はその時点で有効な SQL モードに依存します。モードが設定されていない場合、MySQL は値を範囲の対応するエンドポイントにクリップし、クリップされた値を保存します。ただし、モードが従来型 (「厳密モード」) に設定されている場合、範囲外の値はエラーで拒否され、SQL 標準に従って挿入は失敗します。 「SQL Server モード」を参照してください。

INT 列が UNSIGNED の場合、列範囲のサイズは同じですが、そのエンドポイントは 0 と 4294967295 に変更されます。 -9999999999 と 9999999999 を保存しようとすると、非厳密モードで列に保存される値は 0 と 4294967296 になります。

浮動小数点または固定小数点のカラムに割り当てられた値が、指定された (またはデフォルトの) 精度とスケールで指定された範囲を超える場合、MySQL は範囲の対応するエンドポイントを表す値を非厳密モードで保存します。

MySQL が厳密モードで動作していない場合、クリッピングによる変換は、ALTER TABLE、LOAD DATA INFILE、UPDATE、および複数行の INSERT ステートメントの警告として報告されます。 MySQL が厳密モードで動作している場合、これらのステートメントは失敗し、テーブルがトランザクションであるかどうかやその他の要因に応じて、一部またはすべての値が挿入または変更されません。詳細は、5.3.2項「SQL Serverモード」を参照してください。

11.3. 日付と時刻のタイプ

11.3.1. DATETIME、DATE、TIMESTAMP 型 11.3.2. TIME 型 11.3.4. Y2K に関する事項と日付型

時刻の値を表す DATE および time 型は、時間と年。各 time タイプには、有効な値の範囲と、MySQL が表現できない不正な値を指定するときに使用される「ゼロ」値があります。 TIMESTAMP型は後述する独自の自動更新機能を備えています。

MySQL は、不正な日付を挿入しようとすると、警告またはエラーを出します。 ALLOW_INVALID_DATES SQL モードを使用すると、MySQL が「1999-11-31」などの特定の日付を受け入れることができます。ユーザーが指定した「間違っている可能性がある」値を、今後の処理のためにデータベース (Web フォームなど) に保存したい場合に便利です。このモードでは、MySQL は月の範囲が 0 ～ 12 であり、日の範囲が 0 ～ 31 であることのみを検証します。 MySQL では日/月、および DATE または DATETIME カラムで日が 0 である日付を保存できるため、これらの範囲にはゼロを含めることができます。これは、正確な日付がわからない誕生日をアプリケーションで保存する必要がある場合に便利です。この場合、日付を「1999-00-00」または「1999-01-00」として保存します。 DATE_SUB() や DATE_ADD などの完全な日付を必要とする関数では、そのような日付を保存すると正しい結果が得られません。 (日付にゼロを表示したくない場合は、NO_ZERO_IN_DATE SQL モードを使用できます)。

MySQL では、「0000-00-00」を「疑似日付」として保存することもできます (NO_ZERO_DATE SQL モードが使用されていない場合)。場合によっては、NULL 値を使用するよりもこの方が便利です (データとインデックスが占有するスペースが少なくなります)。

MySQL でサポートしたい日付の種類をより明確に知るには、sql_mode システム変数を対応するモード値に設定します。 「SQL Server モード」を参照してください。

日付と時刻の型を扱うときは、次の点に留意する必要があります:

· MySQL は、指定された日付または時刻の型の値を標準出力形式で取得しますが、さまざまな入力値形式を解釈するために最善を尽くします。指定する場合 (たとえば、日付型または時刻型に割り当てられる値、または日付型または時刻型と比較される値を指定するとき)。次のセクションで説明する形式のみがサポートされます。有効な値を入力してください。他の形式の値を使用すると、予期しない結果が発生する可能性があります。

· 2 桁の年の値が含まれる日付は、世紀が不明なため混乱を招きます。 MySQL は、次のルールを使用して 2 桁の年の値を解釈します:

o 70 ～ 99 の範囲の年の値は、1970 ～ 1999 に変換されます。

o 00 ～ 69 の範囲の年次値は 2000 ～ 2069 に変換されます。

· MySQL は値をいくつかの形式で解釈しようとしますが、日付は、そのままの月-日-年や日-月ではなく、常に年-月-日の順序になります (例: '98-09-04')。他の場所で一般的に使用される - 年のシーケンス (例: '09-04-98'、'04-09-98')。

· MySQL は、値が数値コンテキストで使用されている場合、日付または時刻型の値を数値に自動的に変換し、その逆も同様です。

· MySQL は、(このセクションの冒頭で説明したように) 範囲外またはその型にとって不正な日付または時刻型の値を検出すると、その値をそのクラスの「ゼロ」値に変換します。 1 つの例外は、範囲外の TIME 値が TIME 範囲の対応するエンドポイントにクリップされることです。

以下の表は、さまざまな「ゼロ」値の形式を示しています。 NO_ZERO_DATE SQL モードが有効な場合、これらの値を使用すると警告が生成されることに注意してください。

列タイプ「ゼロ」値

DATETIME '0000-00-00 00:00:00'

DATE '0000-00-00'

TIMESTAMP 00000000000 000

TIME '00:00: 00分

YEAR 0000

· 「ゼロ」値は特別な値ですが、表に示されている値を使用して明示的に保存または参照できます。値「0」または 0 を使用して保存または参照することもでき、この方が書き込みが容易です。

· MyODBC で使用される「ゼロ」の日付または時刻の値は、ODBC がそのような値を処理できないため、MyODBC 2.50.12 以降では自動的に NULL に変換されます。

11.3.1. DATETIME、DATE、および TIMESTAMP 型
MySQL 4.1 以降の

11.3.1.1.
TIMESTAMP 属性

DATETIME、DATE、TIMESTAMP 型は関連しています。このセクションでは、それらの特徴、類似点、相違点について説明します。

日付と時刻の両方の情報を含む値が必要な場合は、DATETIME 型を使用します。 MySQL は、DATETIME 値を「YYYY-MM-DD HH:MM:SS」形式で取得して表示します。サポートされている範囲は「1000-01-01 00:00:00」から「9999-12-31 23:59:59」です。 (「サポートされている」とは、以前の値が機能する可能性はあるものの、保証がないことを意味します)。

DATE 型は、時刻部分を含まずに日付値のみが必要な場合に使用する必要があります。 MySQL は、「YYYY-MM-DD」形式を使用して DATE 値を取得および表示します。サポートされている範囲は「1000-01-01」から「9999-12-31」です。

TIMESTAMP カラムタイプのプロパティは固定されておらず、MySQL のバージョンとサーバーが実行されている SQL モードに依存します。これらのプロパティについては、このセクションで後ほど説明します。

DATETIME、DATE、および TIMESTAMP の値は、一般的な形式を使用して指定できます:

· 'YYYY-MM-DD HH:MM:SS' または 'YY-MM-DD HH:MM:SS' 形式の文字列。 「緩和された」構文が許可されます。日付部分または時刻部分の間の区切り文字として、任意の句読点文字を使用できます。たとえば、「98-12-31 11:30:45」、「98.12.31 11+30+45」、「98/12/31 11*30*45」、「98@12@31 11^30^」などです。 45'は同等です。

· 「YYYY-MM-DD」または「YY-MM-DD」形式の文字列。ここでは「緩和された」構文も許可されます。たとえば、「98-12-31」、「98.12.31」、「98/12/31」、および「98@12@31」は同等です。

· 区切り文字のない「YYYYMMDDHHMMSS」または「YYMMDDHHMMSS」形式の文字列。文字列が日付型に対して意味があると想定されます。たとえば、「19970523091528」と「970523091528」は「1997-05-23 09:15:28」として解釈されますが、「971122129015」は不正であり（意味のない議事録部分がある）、「0000- 00-00 00」になります。 :00:00分。

· 区切り文字のない「YYYYMMDD」または「YYMMDD」形式の文字列。文字列が日付型に対して意味があると想定されます。たとえば、「19970523」と「970523」は「1997-05-23」と解釈されますが、「971332」は不正（意味のない月と日の部分がある）であり、「0000-00-00」になります。

· YYYYMMDDHHMMSS または YYMMDDHHMMSS 形式の数値 (数値が日付タイプとして意味があると仮定)。たとえば、19830905132800 と 830905132800 は「1983-09-05 13:28:00」として解釈されます。

· YYYYMMDD または YYMMDD 形式の数値 (数値が日付型として意味をなすものと仮定)。たとえば、19830905 と 830905 は「1983-09-05」として解釈されます。

· 関数によって返される結果には、NOW() や CURRENT_DATE など、DATETIME、DATE、または TIMESTAMP コンテキストに適した値が含まれます。

無効な DATETIME、DATE、または TIMESTAMP 値は、対応するタイプの「ゼロ」値 ('0000-00-00 00:00:00'、'0000-00-00' または 00000000000000) に変換されます。

日付部分の区切り文字を含む文字列値の場合、日と月の値が10未満の場合は、2桁を指定する必要はありません。 「1979-6-9」は「1979-06-09」と同じです。同様に、時刻部分の区切り文字を含む文字列値の場合、時、分、秒の値が 10 未満の場合は、2 桁を指定する必要はありません。 「1979-10-30 1:2:3」は「1979-10-30 01:02:03」と同じです。

数値の長さは 6、8、12、または 14 桁である必要があります。数値の長さが 8 桁または 14 桁の場合、最初の 4 桁が年を表す YYYYMMDD または YYYYMMDDHHMMSS 形式であるとみなされます。数値の長さが 6 桁または 12 桁の場合、最初の 2 桁が年を表す YYMMDD または YYMMDDHHMMSS 形式であるとみなされます。他の数値は、最も近い長さにゼロが埋め込まれたものとして解釈されます。

非修飾子文字列として指定された値は、指定された長さを使用して解釈されます。文字列の長さが 8 文字または 14 文字の場合、最初の 4 桁は年を表します。それ以外の場合、最初の 2 桁は年を表します。文字列内の各出現箇所を左から右に解釈して、年、月、日、時、分、秒の値を見つけます。これは、6 文字より短い文字列を使用すべきではないことを意味します。たとえば、「9903」を指定すると、1999 年 3 月を意味すると考えられ、MySQL はテーブルに「ゼロ」の日付値を挿入します。これは、年と月の値が 99 と 03 ですが、日の部分が完全に欠落しているため、この値は有効な日付ではないためです。ただし、欠落している月または日の部分を表すゼロ値を明示的に指定できます。たとえば、「990300」を使用して値「1999-03-00」を挿入できます。

ある日付型の値を別の日付型に割り当てることは、ある程度可能です。ただし、値は変更されるか、一部の情報が失われる可能性があります:

· DATE 値を DATETIME または TIMESTAMP オブジェクトに割り当てる場合、DATE 値は変更されないため、結果の値の時刻部分は '00:00:00' に設定されます。時間情報が含まれています。

· DATETIME または TIMESTAMP 値を DATE オブジェクトに代入すると、DATE 値には時間情報が含まれないため、結果の値の時間部分が削除されます。

· DATETIME、DATE、TIMESTAMP の値は同じ形式を使用して指定できますが、値の種類によって範囲が異なることに注意してください。たとえば、TIMESTAMP 値を 1970 より前または 2037 より後にすることはできません。これは、「1968-01-01」などの日付は、DATETIME または DATE 値には有効ですが、TIMESTAMP 値には無効であり、そのようなオブジェクトに割り当てられた場合は 0 に変換されることを示します。

日付値を指定するときは、いくつかの落とし穴に注意してください:

· 文字列として指定された値に許可される非厳密な形式は、欺瞞的な可能性があります。たとえば、値「10:11:12」は「:」区切り文字により時刻値のように見えますが、日付コンテキストで使用される場合、値は年「2010-11-12」として解釈されます。 「45」は法定月ではないため、値「10:45:15」は「0000-00-00」に変換されます。

· 非厳密モードでは、MySQL サーバーは日付の有効性に関する基本的なチェックのみを実行します。年、月、日の範囲はそれぞれ 1000 ～ 9999、00 ～ 12、00 ～ 31 です。これらの範囲外の部分を含む日付は「0000-00-00」に変換されます。 「2002-04-31」などの不正な日付を保存することは依然として許可されていることに注意してください。厳密モードを使用していない場合に日付が有効であることを確認するには、アプリケーションを確認する必要があります。

厳密モードでは、不正な日付は受け入れられず、変換されません。

詳細は、セクション5.3.2「SQL Server モード」を参照してください。

· 2 桁の年の値が含まれる日付は、世紀が不明なため混乱を招きます。 MySQL は、次のルールを使用して 2 桁の年の値を解釈します:

o 00 ～ 69 の範囲の年の値は 2000 ～ 2069 に変換されます。

o 70 ～ 99 の範囲の年次値は 1970 ～ 1999 年に変換されます。

11.3.1.1. MySQL 4.1 以降の TIMESTAMP 属性

注: MySQL の古いバージョン (4.1 より前) では、TIMESTAMP カラムタイプの属性は、このセクションで説明されているものとは多くの点で大きく異なります。古い TIMESTAMP データを MySQL 5.1 で動作するように変換する必要がある場合、詳細については MySQL 4.1 リファレンス マニュアルを参照してください。

TIMESTAMP列の表示形式はDATETIME列と同じです。つまり、表示幅は 19 文字に固定され、形式は YYYY-MM-DD HH:MM:SS となります。

MySQL サーバーは MAXDB モードでも実行できます。サーバーがこのモードで実行されている場合、TIMESTAMP は DATETIME と等しくなります。つまり、テーブルの作成時にサーバーが MAXDB モードで実行されている場合、TIMESTAMP 列は DATETIME 列として作成されます。その結果、列は DATETIME 表示形式を使用し、同じ値の範囲を持ち、現在の日付と時刻で自動的に初期化または更新されません。

MAXDB モードを有効にするには、サーバーの起動時に –sql-mode=MAXDB サーバー オプションを使用するか、グローバル sql_mode 変数を設定して実行時に SQL サーバー モードを MAXDB に設定します。

クライアントは次のようにすることができます。メソッド 接続のためにサーバーを MAXDB モードで実行します:

MySQL は、日または月の列にゼロを含むタイムスタンプ値、または不正な日付値を含むタイムスタンプ値を受け入れません。このルールの唯一の例外は、特別な値「0000-00-00 00:00:00」です。

TIMESTAMP をいつ初期化して更新するか、またどの列を初期化して更新するかを非常に柔軟に決定できます:

· 現在のタイムスタンプをデフォルト値および自動的に更新される値として指定できます。ただし、どちらか一方のみを選択することも、どちらも選択しないこともできます。 (ある列で 1 つの動作を選択し、別の列で別の動作を選択することはできません)。

· どの TIMESTAMP 列を自動的に初期化するか、現在の日時に更新するかを指定できます。 1 番目の TIMESTAMP 列は必要なくなりました。

以下で説明する情報は、MAXDB モードを有効にせずに作成されたテーブルの TIMESTAMP 列にのみ適用されることに注意してください。 (前述したように、MAXDB モードでは列が DATETIME 列として作成されます)。 TIMESTAMP 列の初期化と更新を制御するルールは次のとおりです:

· テーブル内の最初の TIMESTAMP 列が DEFAULT 値として指定されている場合、それを無視することはできません。 デフォルト値は CURRENT_TIMESTAMP または定数の日付と時刻の値です。

・DEFAULT NULLは、1番目のTIMESTAMP列のDEFAULT CURRENT_TIMESTAMPと同じです。他の TIMESTAMP 列の場合、DEFAULT NULL は DEFAULT 0 として扱われます。

· テーブル内の TIMESTAMP 列は、現在のタイムスタンプに自動的に初期化されたり、更新されるように設定できます。

· CREATE TABLE ステートメントでは、次のいずれかの方法で最初の TIMESTAMP 列を宣言できます:

o DEFAULT CURRENT_TIMESTAMP 句と ON UPDATE CURRENT_TIMESTAMP 句を使用して、現在のタイムスタンプをデフォルト値として使用し、自動的に更新します。

o DEFAULT CURRENT_TIMESTAMP ON UPDATECURRENT_TIMESTAMP と同様に、DEFAULT または ON UPDATE 句を使用しません。

o ON UPDATE 句の代わりに DEFAULT CURRENT_TIMESTAMP 句を使用します。列は現在のタイムスタンプをデフォルト値として使用しますが、自動的には更新されません。

o DEFAULT 句を使用せず、ON UPDATE CURRENT_TIMESTAMP 句を使用すると、列のデフォルト値は 0 になり、自動的に更新されます。

o 定数の DEFAULT 値を使用します。指定されたデフォルト値がリストされています。列に ON UPDATE CURRENT_TIMESTAMP 句がある場合は自動的に更新されますが、それ以外の場合は更新されません。

言い換えると、初期値と自動的に更新される値に現在のタイムスタンプを使用することも、どちらか一方を使用することも、どちらも使用しないこともできます。 (たとえば、ON UPDATE を指定すると、列を自動的に初期化せずに自動更新を有効にすることができます)。

· DEFAULT 句と ON UPDATE 句では、CURRENT_TIMESTAMP、CURRENT_TIMESTAMP()、または NOW() を使用できます。それらはすべて同じ効果があります。

2 つのプロパティの順序は重要ではありません。 DEFAULT と ON UPDATE の両方が TIMESTAMP 列に指定されている場合は、どちらかを他方よりも優先できます。

例、次のステートメントは同等です:

· 列 1 以外の TIMESTAMP 列の自動デフォルトまたは更新を指定するには、最初の TIMESTAMP 列に定数 DEFAULT 値を明示的に割り当てて、自動初期化と更新を無効にする必要があります。 (たとえば、DEFAULT 0 または DEFAULT’2003-01-01 00:00:00’)。次に、他の TIMESTAMP 列のルールは、DEFAULT 句と ON UPDATE 句を無視できないことを除いて、最初の TIMESTAMP 列の場合と同じです。これを行うと、初期化や更新は自動的には行われません。

例: 次のステートメントは同等です:

各接続の現在のタイムゾーンを設定できます。関連する説明については、セクション5.10.8「MySQL サーバーのタイムゾーンのサポート」を参照してください。 TIMESTAMP 値は UTC 形式で保存され、保存時に現在のタイムゾーンに変換され、取得時に現在のタイムゾーンに逆変換されます。タイムゾーン設定値が定数であれば保存時の値を取得できます。 TIMESTAMP 値を保存する場合は、タイムゾーンを変更してから値を取得する必要があります。保存した値とは異なります。これは、両方向の変換に同じタイムゾーンが使用されないためです。現在のタイムゾーンは、time_zone システム変数の値として使用できます。

TIMESTAMP 列の定義に NULL 属性を含めて、列に NULL 値を含めることができます。例:

NULL 属性が指定されていない場合、列を NULL に設定すると、現在のタイムスタンプが設定されます。 NULL 値を許可する TIMESTAMP 列は、デフォルト値が CURRENT_TIMESTAMP として定義されているか、NOW() または CURRENT_TIMESTAMP が列に挿入されていない限り、現在のタイムスタンプを想定しないことに注意してください。つまり、NULL として定義された TIMESTAMP 列は、次のような定義で作成された場合にのみ自動的に更新されます:

それ以外の場合 - つまり、次に示すように、TIMESTAMP 列が DEFAULT TIMESTAMP ではなく NULL で定義されている場合です。以下...

… 次に、現在の日付と時刻に対応する値を明示的に挿入する必要があります。例:

11.3.2. TIME タイプ

MySQL は、TIME 値を「HH:MM:SS」形式 (または、大きな時間値の場合は「HHH:MM:SS」形式) で取得して表示します。 。 TIME 値の範囲は「-838:59:59」から「838:59:59」です。時間の部分が非常に大きい理由は、TIME 型を使用して時刻 (24 時間未満である必要がある) だけでなく、イベントの経過時間やイベント間の時間間隔も表すことができるためです。イベント (24 時間を超える場合や、マイナスの場合もあります)。

TIME 値はさまざまな形式で指定できます:

· 'D HH:MM:SS.fraction' 形式の文字列。次の「非厳密」構文のいずれかを使用することもできます: 'HH:MM:SS.fraction'、'HH:MM:SS'、'HH:MM'、'D HH:MM:SS'、'D HH: MM'、'D HH'、または 'SS'。ここで、D は日を表し、0 ～ 34 の値を取ることができます。 MySQL はまだスコアを保存しないことに注意してください。

· 意味のある時刻を想定した、区切り文字のない「HHMMSS」形式の文字列。たとえば、「101112」は「10:11:12」として理解されますが、「109712」は不正（意味のない分部分がある）であるため、「00:00:00」になります。

· HHMMSS 形式の値。意味のある時刻であると想定されます。たとえば、101112 は「10:11:12」として理解されます。 SS、MMSS、HHMMSS、HHMMSS.fraction の形式も理解されます。 MySQL はまだスコアを保存しないことに注意してください。

· CURRENT_TIME など、TIME コンテキストに適した値を持つ関数によって返された結果。

時刻部分の区切り文字を含む文字列で指定するTIME値について、時、分、秒の値が10未満の場合は2桁の指定は不要です。 「8:3:2」は「08:03:02」と同じです。

TIME列に短縮値を割り当てる場合は注意してください。コロンがないと、MySQL は右端の 2 桁が秒を表すものとして値を解釈します。 (MySQL は、TIME 値をその日の時刻ではなく過去の時刻として解釈します)。たとえば、「1112」と 1112 は「11:12:00」(11 時 11 分) を意味すると考えるかもしれませんが、MySQL はそれらを「00:11:12」(11 分 12 秒) として解釈します。同様に、「12」と 12 は「00:00:12」として解釈されます。対照的に、TIME 値内のコロンは常に時刻として扱われます。つまり、「11:12」は「00:11:12」ではなく「11:12:00」を意味します。

TIME 範囲外だが正当な値は、範囲の最も近い端点にクリップされます。たとえば、「-850:00:00」と「850:00:00」は「-838:59:59」と「838:59:59」に変換されます。

無効なTIME値は「00:00:00」に変換されます。 「00:00:00」自体は正当な TIME 値であるため、テーブルに保存された「00:00:00」値だけでは、元の値が「00:00:00」であるか不正な値であるかを判断できないことに注意してください。 。

11.3.3。

YEAR型は年を表すために使用される半角型です。

MySQL は、YEAR 値を YYYY 形式で取得して表示します。範囲は 1901 ～ 2155 です。

YEAR 値はさまざまな形式で指定できます:

· '1901' から '2155' までの 4 桁の文字列。

· 1901 から 2155 までの 4 桁。

· 「00」から「99」までの 2 桁の文字列。 「00」から「69」および「70」から「99」の範囲の値は、2000から2069および1970から1999の範囲のYEAR値に変換されます。

・1〜99の範囲の2桁の整数。1〜69および70〜99の範囲の値は、2001〜2069および1970〜1999の範囲のYEAR値に変換されます。 2 桁の整数の範囲は、ゼロを数値として直接指定して 2000 として解釈することができないという点で、2 桁の文字列の範囲とは若干異なることに注意してください。文字列「0」または「00」として指定する必要があります。指定しない場合は、0000 として解釈されます。

· NOW() など、関数によって返される結果。その値は YEAR コンテキストに適しています。

不正な YEAR 値は 0000 に変換されます。

11.3.4. Y2K の問題と日付タイプ

MySQL 自体は 2000 年 (Y2K) に対して安全ですが (セクション1.4.5「2000 年の互換性」を参照)、MySQL に入力される値は安全ではない可能性があります。安全 。 2 桁の年の値を含む入力は、世紀が不明であるためあいまいになります。 MySQL は内部で年を格納するために 4 桁を使用するため、これらの値は 4 桁として解釈する必要があります。

DATETIME、DATE、TIMESTAMP、YEAR 型の場合、MySQL は次のルールを使用して、あいまいな年の値を持つ日付を解釈します:

· 00 ～ 69 の範囲の年の値は 2000 ～ 2069 に変換されます。

· 70 ～ 99 の範囲の年次値は 1970 ～ 1999 年に変換されます。

これらのルールは、データ値が何を表すかについての合理的な推測にすぎないことを覚えておいてください。 MySQL で使用されるヒューリスティックが正しい値を生成しない場合は、4 桁の年の値を含む正確な入力を提供する必要があります。

ORDER BY は、2 桁の年を使用して TIMESTAMP または YEAR 値を正しく並べ替えることができます。

MIN() や MAX() などの一部の関数は、TIMESTAMP または YEAR を数値に変換します。これは、これらの関数が 2 桁の年の値を持つ値では正しく機能しないことを意味します。この場合の修正方法は、TIMESTAMP または YEAR を 4 桁の年の形式に変換するか、MIN(DATE_ADD(TIMESTAMP,INTERVAL 0 DAYS)) を使用することです。

11.4. 文字列型

11.4.2.

BINARY 型と VARBINARY 型 11.4.4. SET 型

文字列型とは、CHAR、VARCHAR、BINARY、VARBINARY、BLOB、TEXT、ENUM、SET を指します。このセクションでは、これらの型がどのように機能するか、およびクエリでの使用方法について説明します。

11.4.1. CHAR 型と VARCHAR 型

CHAR 型と VARCHAR 型は似ていますが、保存方法と取得方法が異なります。また、最大長と末尾のスペースが保持されるかどうかという点でも異なります。保存または取得中に大文字と小文字の変換は実行されません。

CHAR 型と VARCHAR 型の宣言された長さは、保存する最大文字数を示します。たとえば、CHAR(30) は 30 文字を占めることができます。

CHARカラムの長さはテーブル作成時に宣言した長さに固定されます。長さは 0 ～ 255 の任意の値にすることができます。 CHAR 値を保存するときは、指定した長さまで右側にスペースを埋め込みます。 CHAR 値を取得すると、末尾のスペースが削除されます。保存または取得中に大文字と小文字の変換は実行されません。

VARCHAR 列の値は可変長文字列です。長さは 0 ～ 65,535 の値で指定できます。 (VARCHAR の最大有効長は、最大行サイズと使用される文字セットによって決まります。全体の最大長は 65,532 バイトです)。

CHAR と比較して、VARCHAR 値が保存される場合、必要な数の文字のみが保存され、さらに長さを記録するために 1 バイトが保存されます (列の宣言された長さが 255 を超える場合は、2 バイトが使用されます)。

VARCHAR 値はパディングなしで保存されます。標準 SQL に準拠して、値の保存および取得時に末尾のスペースが保持されます。

CHAR または VARCHAR 列に割り当てられた値が列の最大長を超える場合、値は収まるようにクリップされます。切り捨てられた文字がスペースでない場合は、警告が生成されます。スペース以外の文字がトリミングされると、(警告ではなく) エラーが発生し、厳密な SQL モードを使用した値の挿入が無効になります。 「SQL Server モード」を参照してください。

以下の表は、さまざまな文字列値を CHAR(4) 列と VARCHAR(4) 列に保存した後の結果を示し、CHAR と VARCHAR の違いを示しています:


値 CHAR(4) ストレージ要件 VARCHAR (4) ストレージ要件

" " ' 4 バイト " 1 バイト

'ab' 'ab' 4 バイト 'ab ' 3 バイト

'abcd' 'abcd' 4 バイト 'abcd' 5 バイト

'abcdefgh' 'abcd' 4 bytes 'abcd' 5 バイト

上記の表の最後の行の値は、厳密モードが使用されていない場合にのみ適用されることに注意してください。MySQL が厳密モードで実行されている場合、列の長さを超える値は保存されません。エラーが発生します。

CHAR(4) 列と VARCHAR(4) 列から取得される値は、取得時に CHAR 列から末尾のスペースが削除されるため、必ずしも同じではありません。違いを次の例で示します:

CHAR 列と VARCHAR 列の値を、列に割り当てられた文字セットの照合規則に従って並べ替えて比較します。

すべての MySQL 照合ルールは PADSPACE クラスに属していることに注意してください。これは、MySQL のすべての CHAR 値と VARCHAR 値を比較するときに、末尾のスペースを考慮する必要がないことを意味します。例:

これはすべての MySQL バージョンに当てはまり、SQL サーバー モードの影響を受けないことに注意してください。

比較中に末尾のパディング文字が切り取られるか無視される状況で、列のインデックスに一意の値が必要な場合、パディング文字の数だけが異なる値を列に挿入すると、コピー キー エラーが発生します。

CHAR BYTE は CHAR BINARY の別名です。これは互換性を確保するためです。

ASCII 属性は、latin1 文字セットを CHAR 列に割り当てます。 UNICODE 属性は、u​​cs2 文字セットを割り当てます。

11.4.2. BINARY および VARBINARY 型

BINARY クラスと VARBINARY クラスは、非バイナリ文字列ではなくバイナリ文字列を含むことを除いて、CHAR および VARCHAR と似ています。つまり、文字列ではなくバイト列が含まれます。これは、文字セットがなく、並べ替えと比較が列値バイトの数値に基づいて行われることを意味します。

BINARY と VARBINARY の最大許容長は、CHAR と VARCHAR と同様に同じです。違いは、BINARY と VARBINARY の長さが文字の長さではなくバイトの長さであることです。

BINARY および VARBINARY データ型は、CHAR BINARY および VARCHAR BINARY データ型とは異なります。後者のタイプの場合、BINARY プロパティは列をバイナリ文字列列として扱いません。代わりに、列の文字セットのバイナリ照合規則が使用され、列自体にバイナリ バイト文字列ではなく非バイナリ文字列が含まれるようになります。たとえば、デフォルトの文字セットが latin1 であると仮定すると、CHAR(5) BINARY は CHAR(5) CHARACTER SET latin1 COLLATE latin1_bin として扱われます。これは、文字セットや照合規則を持たない 5 バイトのバイナリ文字列を保持する BINARY(5) とは異なります。

BINARY 値を保存するときは、指定された長さまで値を右側に埋め込みます。パディング値は 0x00 (ゼロバイト) です。値を挿入するときに右側に 0×00 を追加し、選択するときに末尾のバイトを削除しません。比較する場合は、ORDER BY および DISTINCT 操作を含むすべてのバイトが重要です。比較すると、0×00バイトとスペースは異なり、0×00＜スペースとなります。

例: BINARY(3) 列の場合、「a」は挿入されると「a 」になります。 「a」を挿入すると「a」になります。どちらの挿入値も選択しても変更されません。

VARBINARY の場合、文字は挿入時に埋め込まれず、選択時にバイトはトリミングされません。比較する場合は、ORDER BY および DISTINCT 操作を含むすべてのバイトが重要です。比較すると、0×00バイトとスペースは異なり、0×00＜スペースとなります。

比較中に末尾のパディング文字が切り取られるか無視される状況で、列のインデックスに一意の値が必要な場合、パディング文字の数だけが異なる値を列に挿入すると、コピー キー エラーが発生します。

これらのデータ型を使用してバイナリ データを保存する予定で、保存された値とまったく同じ値を取得する必要がある場合は、前述のパディング機能とクリッピング機能を考慮する必要があります。次の例は、0×00 で埋められた BINARY 値が列値の比較にどのように影響するかを示しています。 BLOB データ型。

MySQL は、テーブルの作成時に BINARY または VARBINARY カラムの型をサイレントに変更できます。セクション13.1.5.1「サイレントカラム仕様の変更」を参照してください。

11.4.3. BLOB 型と TEXT 型

BLOB は、可変量のデータを保持できるバイナリ ラージ オブジェクトです。 BLOB タイプには、TINYBLOB、BLOB、MEDIUMBLOB、LONGBLOB の 4 つがあります。値を保持できる最大長が異なるだけです。

テキストには、TINYTEXT、TEXT、MEDIUMTEXT、LONGTEXTの 4 つのタイプがあります。これらは、同じ最大長とストレージ要件を持つ 4 つの BLOB タイプに対応します。

セクション11.5「列タイプのストレージ要件」を参照してください。

BLOB列はバイナリ文字列(バイト文字列)として扱われます。 TEXT 列は非バイナリ文字列 (文字列) として扱われます。 BLOB 列には文字セットがなく、並べ替えと比較は列値のバイトの数値に基づいて行われます。 TEXT 列には文字セットがあり、値は文字セットの照合規則に従って並べ替えおよび比較されます。

TEXT 列または BLOB 列の格納または取得中に大文字と小文字の変換は行われません。

厳密モードで実行していない場合、列タイプの最大長を超える値を BLOB または TEXT 列に割り当てると、値は適合するように切り詰められます。切り捨てられた文字がスペースでない場合は、警告が生成されます。厳密な SQL モードを使用すると、エラーが生成され、値は警告でインターセプトされずに拒否されます。 「SQL Server モード」を参照してください。

ほとんどの点で、BLOB 列は十分な大きさを持つ VARBINARY 列と考えることができます。同様に、TEXT 列は VARCHAR 列として扱うことができます。 BLOB および TEXT は、次の点で VARBINARY および VARCHAR と異なります:

· BLOB 列および TEXT 列から値を保存または取得するときに、末尾のスペースは削除されません。 (これは、VARBINARY 列および VARCHAR 列と同じです)。

CHAR や VARCHAR と同様に、TEXT は比較されるオブジェクトに合わせてスペースを使用して展開されることに注意してください。

· BLOB 列と TEXT 列のインデックスの場合、インデックスの接頭辞の長さを指定する必要があります。 CHAR および VARCHAR の場合、接頭辞の長さはオプションです。 「列インデックス」を参照してください。

· BLOB 列と TEXT 列にはデフォルト値を設定できません。

LONG および LONG VARCHAR は MEDIUMTEXT データ型に対応します。これは互換性を確保するためです。 TEXT 列タイプで BINARY 属性が使用されている場合、列には列文字セットのバイナリ照合順序が割り当てられます。

MySQL コネクタ/ODBC は、BLOB 値を LONGVARBINARY として定義し、TEXT 値を LONGVARCHAR として定義します。

BLOB 値と TEXT 値は非常に長くなる可能性があるため、使用するときにいくつかの制約が発生する可能性があります:

· 並べ替え時には、列の最初の max_sort_length バイトのみが使用されます。 max_sort_length のデフォルト値は 1024 ですが、この値は mysqld サーバーの起動時に –max_sort_length オプションを使用して変更できます。第5.3.3項「サーバーのシステム変数」を参照してください。

実行時に max_sort_length の値を増やすと、並べ替えまたは結合するときにより多くのバイトが意味を持つようになります。どのクライアントもセッションの max_sort_length 変数の値を変更できます:

max_sort_length より多くのバイトを意味のあるものにしたい場合は、長い値を含む BLOB または TEXT 列に対して別の GROUP BY または ORDER BY を使用します。列の値を固定長オブジェクトに変換します。標準的なアプローチは、SUBSTRING 関数を使用することです。たとえば、次のステートメントはコメント列の 2000 バイトをソートします:

· BLOB または TEXT オブジェクトの最大サイズはその型によって決まりますが、実際にクライアントとサーバー間で受け渡すことができる最大値は使用可能なメモリの量と通信バッファのサイズが決まります。 max_allowed_pa​​cket 変数の値を変更することでメッセージ バッファのサイズを変更できますが、サーバー プログラムとクライアント プログラムの両方を変更する必要があります。たとえば、mysql と mysqldump を使用して、クライアントの max_allowed_pa​​cket 値を変更できます。 「サーバー・パラメータの調整」、「mysql: MySQL コマンドライン・ツール」、および「mysqldump: データベース・バックアップ・プログラム」を参照してください。

各 BLOB または TEXT 値は、それぞれ内部的に割り当てられたオブジェクトによって表されます。これは、テーブルを開いたときに各列にストレージ エンジンを割り当てる他の列タイプとは対照的です。

11.4.4. ENUM 型

ENUM は、テーブルの作成時に列仕様で明示的に列挙された値の列から値が取得される文字列オブジェクトです。

場合によっては、ENUM 値が空の文字列 (") または NULL になることもあります:

· ENUM に不正な値 (つまり、許可された値列外の文字列) を挿入すると、空の文字列が挿入されます。この文字列は、数値 0 を持つ「通常の」空の文字列とは異なります。

· ENUM 列が NULL を許可するように宣言されている場合、NULL 値が有効です。列の値であり、デフォルト値は NULL です。ENUM 列が NOT NULL として宣言されている場合、そのデフォルト値は、許可される値列の最初の要素です。

各列挙値に対して 1 つのインデックスがあります。

· 値

· 空の文字列エラー値のインデックス値は 0 です。これは、次の SELECT ステートメントを使用して、不正な ENUM を持つ行を検索できることを意味します。値:

· NULL 値のインデックスは NULL です

たとえば、ENUM ('one'、'two'、'three') として定義された列は、以下に示すように任意の値を持つことができます。値の:

値インデックス

NULL NULL

” 0

'one' 1

'two' 2

'three' 3

列挙には最大 65,535 個の要素を含めることができます。

テーブルを作成するとき、ENUMメンバー値の末尾のスペースは自動的に削除されます。

取得時、ENUM列に格納されている値は列定義で使用されている大文字と小文字を使用して表示されます。 ENUM 列には文字セットと照合規則を割り当てることができることに注意してください。バイナリまたは大文字と小文字を区別する照合ルールの場合、列に値を割り当てるときに大文字と小文字を考慮する必要があります。

ENUM 値が数値コンテキストで取得された場合、列値のインデックスが返されます。たとえば、次のように ENUM 列から数値を検索できます:

数値を ENUM 列に保存すると、その数値はインデックスとして扱われ、保存された値が列挙メンバーになります。そのインデックスに対応します。 (ただし、これは、すべての入力を文字列として扱う LOAD DATA では機能しません)。混乱を招きやすいため、数値のような列挙値を使用して ENUM 列を定義することはお勧めできません。たとえば、次の列には、文字列値 '0'、'1'、および '2' を持つ列挙型メンバーが含まれていますが、数値インデックス値 1、2、および 3 が含まれています。列定義のメンバー ENUM 値はリストされた順序でソートされます。 (つまり、ENUM 値はインデックス番号に従ってソートされます)。たとえば、ENUM('a', 'b') の場合、'a' は 'b' の前に来ますが、ENUM('b', 'a') の場合、'b' は 'a' の前に来ます。空の文字列は空でない文字列より前に並べ替えられ、NULL 値は他のすべての列挙値より前に並べ替えられます。予期しない結果を防ぐには、ENUM 列をアルファベット順に指定します。 GROUP BY CAST(col AS CHAR) または GROUP BY CONCAT(col) を使用して、列が数値ではなく字句に従ってソートされるようにすることもできます。

ENUM 列のすべての可能な値を確認したい場合は、SHOW COLUMNS FROM tbl_name LIKE enum_col を使用し、出力内の列 2 の ENUM 定義を解析します。

11.4.5. SET タイプ

SET は 0 個以上の値を持つことができる文字列オブジェクトであり、その値はテーブルの作成時に指定された許容値のリストから取得されます。複数の SET メンバーを含む SET 列の値を指定する場合は、カンマ (「,」) を使用して各メンバーを区切ります。このように、SET メンバー値自体にカンマを含めることはできません。

たとえば、SET('one', 'two') NOT NULL として指定された列には、次のいずれかの値を含めることができます:

SET は、最大 64 個の異なるメンバーを含めることができます。

テーブルを作成するとき、SETメンバー値の末尾のスペースは自動的に削除されます。

取得時、SET列に格納された値は列定義で使用されている大文字と小文字を使用して表示されます。 SET 列には文字セットと照合規則を割り当てることができることに注意してください。バイナリまたは大文字と小文字を区別する照合ルールの場合、列に値を割り当てるときに大文字と小文字を考慮する必要があります。

MySQL は SET 値を数値として保存し、保存された値の下位ビットは最初の SET メンバーに対応します。 SET 値が数値コンテキストで取得された場合、取得された値のビット設定は、列値を構成する SET メンバーに対応します。たとえば、次のように SET 列から数値を取得できます:





数値を SET 列に保存すると、数値のバイナリ表現のビットによって列値の SET メンバーが決まります。 SET('a','b','c','d') として指定された列の場合、メンバーは次の 10 進値とバイナリ値を持ちます:

SET メンバー 10 進値 2 進値

'a' 1 0001

'b' 2 0010

'c' 4 0100

'd' 8 1000

この列に値 9 を割り当てると、そのバイナリ形式は 1001 になるため、1 番目と 4 番目の SET 値のメンバーの a'および 'd' が選択され、結果の値は 'a,d' になります。

複数の SET 要素を含む値の場合、値を挿入するときに要素がリストされる順序は関係ありません。特定の要素が値に何回リストされているかは関係ありません。後で値が取得されると、値内の各要素が 1 回表示され、テーブルの作成時に指定された順序で要素がリストされます。たとえば、列が SET('a','b','c','d') として指定されているとします。

値 'a,d','d,a' を挿入します。 、'a, d,d'、'a,d,a' および 'd,a,d':

これらの値はすべて、取得時に 'a,d' として表示されます:

SET 列がサポートされていない値に設定されている場合、その値は無視され、警告が発行されます:

SET 値は数値順に並べ替えられます。 NULL 値は、非 NULL SET 値の前にソートされます。

通常、FIND_IN_SET() 関数または LIKE 演算子を使用して SET 値を検索できます。

最初のステートメントは、SET_col に値セットのメンバーが含まれる行を検索します。 2 番目のものは似ていますが、異なります。set_col が他の場所 (別の SET メンバーの部分文字列であっても) に値を含む行を検索します。

次のステートメントも有効です:

最初のステートメントは、最初のセット メンバーを含む値を検索します。 2 番目のステートメントは、完全に一致する値を検索します。カテゴリ 2 の比較に注意を払う必要があります。設定値を「val1, val2」と比較して返される結果は、設定値を「val2, val1」と比較して返される結果が異なります。値は、列定義にリストされているのと同じ順序で指定する必要があります。

SET 列のすべての可能な値を確認したい場合は、SHOW COLUMNS FROM tbl_name LIKE set_col を使用し、出力の列 2 の SET 定義を解析します。

11.5. カラムタイプのストレージ要件

MySQL でサポートされている各カラムタイプのストレージ要件をカテゴリ別にリストします。

MyISAM テーブルの行の最大サイズは 65,534 バイトです。各 BLOB 列と TEXT 列は、そのうちの 5 ～ 9 バイトのみを占めます。

MyISAM テーブルに可変長の列タイプが含まれる場合、レコード形式も可変長になります。テーブルを作成するとき、MySQL は特定の条件下でカラムを可変長タイプから固定長タイプに、またはその逆に変更できます。詳細については、「サイレントカラム仕様の変更」を参照してください。

数値型の記憶域要件

列型の記憶域要件

TINYINT 1バイト

SMALLINT 2バイト

MEDIUMINT 3バイト

INT、INTEGER 4バイト

BIGINT 8バイト

FLOAT(p) 0

FLOAT 4 バイト

DOUBLE [PRECISION] 、項目 REAL 8 バイト

DECIMAL(M,D), NUMERIC( M,D) 可変長; 以下の説明を参照

BIT(M) 約 (M+7)/8 バイト

DECIMAL( および NUMERIC) ストレージ要件はバージョン固有です:

10 進数 9 を圧縮するにはバイナリ形式を使用します (ベース) 10) 数値を 4 バイトに分割して DECIMAL 列の値を表します。各値の整数部と小数部の格納方法は個別に決定されます。 9 桁の各倍数には 4 バイトが必要で、「残りの」ビットには 4 バイトの一部が必要です。次の表に、過剰ビットのストレージ要件を示します。

残りのバイト

ビット数

0 0

1 1

2 1

3 2

4 2

5 3

6 3

7 4 4

8 4

9 4

日付と時刻型の記憶域要件

列型の記憶域要件

DATE 3バイト

DATETIME 8バイト

TIMESTAMP 4ワード セクション

時間3バイト

YEAR 1 バイト

文字列型の記憶域要件

列型の記憶域要件

CHAR(M) M バイト、0

VARCHAR(M) L+1 バイト、L

BINARY(M) M バイト、0

VARBINARY(M) L+1 バイト、L

TINYBLOB、TINYTEXT L+1 バイト、L

BLOB、TEXT L+2 バイト、L

MEDIUMBLOB、MEDIUMTEXT L+ 3 バイト、L

LONGBLOB、LONGTEXT L+4 バイト、L

ENUM('value1','value2',…) 列挙値の数に応じて 1 バイトまたは 2 バイト(最大 65,535 個の値)

SET('value1','value2',…) セット メンバーの数に応じて 1、2、3、4 または 8 バイト (最大 64 メンバー)

VARCHAR、BLOB、TEXT クラスは可変長型です。各型の記憶域要件は、型の最大許容サイズではなく、列値の実際の長さ (上の表では L で示されています) によって決まります。たとえば、VARCHAR(10) 列には、最大長 10 の文字列を保持できます。実際のストレージ要件は、文字列の長さ (L) に、文字列の長さを記録するバイトを加えたものです。文字列「abcd」の場合、L は 4 であり、記憶域には 5 バイトが必要です。

CHAR、VARCHAR、TEXT 型の場合、前の表の値 L と M は文字数として解釈され、列定義内のこれらの型の長さが文字数を表します。たとえば、TINYTEXT 値を保存するには、L 文字 +
1 バイトが必要です。

特定の CHAR、VARCHAR、または TEXT 列の値を格納するために使用されるバイト数を計算するには、その列で使用されている文字セットを考慮する必要があります。 Unicode を使用する場合、すべての Unicode 文字が同じバイト数を使用することに留意する必要があります。 Unicode 文字のさまざまなクラスによって使用されるストレージの内訳については、「Unicode サポート」を参照してください。

注: VARCHAR 列の有効な最大長は 65,532 文字です。

NDBCLUSTER エンジンは固定幅の列のみをサポートします。これは、MySQL Cluster のテーブル内の VARCHAR カラムが CHAR 型のように動作することを意味します (ただし、各レコードにはまだ余分なバイトのスペースが残っています)。たとえば、Cluster テーブルでは、VARCHAR(100) として宣言された列の各レコードは、実際に格納されるレコードの文字列の長さに関係なく、格納時に 101 バイトを占有します。

BLOB クラスと TEXT クラスでは、クラスの最大可能長に応じて、列値の長さを記録するために 1、2、3、または 4 バイトが必要です。セクション11.4.3「BLOB 型と TEXT 型
」を参照してください。

NDB Cluster ストレージ エンジンでは、TEXT 列と BLOB 列の実装が異なり、TEXT 列の各レコードは 2 つの別個の部分で構成されます。 1 つは固定サイズ (256 バイト) で、実際には元のテーブルに保存されます。もう 1 つは、暗黙的なテーブルに保持される 256 バイトを超えるデータを含みます。 2 番目のテーブルのレコードの長さは常に 2,000 バイトです。これは、size+size+(2000–(size–256)%2000) であることを意味します。

ENUM オブジェクトのサイズは、異なる列挙値の数によって決まります。列挙には 1 バイトが使用され、255 個の可能な値を含めることができます。列挙値が 256 ～ 65,535 の場合、2 バイトが使用されます。 「ENUM タイプ」を参照してください。

SET オブジェクトのサイズは、異なるセット メンバーの数によって決まります。設定サイズが N の場合、オブジェクトは (N+7)/8 バイトを占め、1、2、3、4、または 8 バイトに四捨五入されます。 SET には最大 64 のメンバーを含めることができます。 「SET タイプ」を参照してください。

11.6. 適切な列タイプの選択

ストレージを最適化するには、どのような場合でも最も正確なタイプを使用する必要があります。たとえば、列の値の範囲が 1 ～ 99999 の場合、整数を使用する場合は MEDIUMINT
UNSIGNED が適切な型です。この型は、列値を表すことができるすべての型の中で最も少ないストレージを使用します。

DECIMAL 列のすべての基本的な計算 (+、-、​​、/) を、10 進数 65 桁 (10 を基準) の精度で実行します。 「数値型の概要」を参照してください。

倍精度演算を使用して、DECIMAL 値の計算を実行します。精度をあまり重視しない場合、または速度を最優先する場合は、DOUBLE タイプで十分です。高精度を実現するために、BIGINT に格納されている固定小数点型への変換を実行できます。これにより、すべての計算を 64 ビット整数で実行できるようになり、必要に応じて結果を浮動小数点値に変換し直すことができます。

11.7. 他のデータベースエンジンのカラムタイプの使用

他のベンダーによって作成された SQL 実行コードを使用するために、MySQL は次の表に示すようにカラムタイプをマップします。テーブル定義は、次のマッピングを通じて他のデータベース エンジンから MySQL に簡単にインポートできます:

その他のセラー タイプ MySQL タイプ

BOOL、TINYINT

BOOLEAN TINYINT

CHAR VARYING(M) VARCHAR(M)

DEC DECIMAL

固定 10 進数

FLOAT4 FLOAT

FLOAT8 DOUBLE

INT1 TINYINT

INT2 SMALLINT

INT3 MEDIUMINT

INT4 INT

INT8 BIGINT

LONG VARBINARY MEDIUMBLOB

LONG VARCHAR MEDIUMTEXT

LONG MEDIUMTEXT

MIDDLEINT MEDIUMINT

NUMERIC DECIMAL

列の型はテーブルの作成時にマップされ、元の型定義は破棄されます。別のベンダーのタイプを使用してテーブルを作成し、DESCRIBE tbl_name ステートメントを実行すると、MySQL は同等の MySQL タイプを使用してテーブルの構造をレポートします。

上記は MySQL 学習シリーズ 3: データ型の内容です。さらに関連する内容については、PHP 中国語 Web サイト (www.php.cn) に注目してください。