6. MySQL SQL言語リファレンス

MySQL は非常に複雑でありながら、直感的に使用できる覚えやすい SQL インタフェースです。この章では、MySQL を効率的かつ効果的に使用するために知っておく必要がある、さまざまなコマンド、データ型、および関数について説明します。また、この章から、MySQL に組み込まれているすべての機能について参照することもできます。多岐にわたるインデックスの中からそれぞれの内容を参照することによって、この章を効果的に使用することができます。

6.1 言語構造
6.2 カラム型
6.3 SELECT 節と WHERE 節で使用する関数
6.4 データの操作: SELECT、INSERT、UPDATE、DELETE
6.5 データ定義: CREATE、DROP、ALTER
6.6 MySQL 基本ユーザユーティリティコマンド
6.7 MySQL トランザクションコマンドとロックコマンド
6.8 MySQL 全文検索
6.9 MySQL クエリキャッシュ

6.1 言語構造

6.1.1 リテラル:文字列と数値の記述方法
6.1.2 データベース名、テーブル名、インデックス名、カラム名、エイリアス名
6.1.3 名前におけるケース依存
6.1.4 ユーザ変数
6.1.5 システム変数
6.1.6 コメント構文
6.1.7 MySQL での予約語の扱い

6.1.1 リテラル:文字列と数値の記述方法

6.1.1.1 文字列
6.1.1.2 数値
6.1.1.3 16 進値
6.1.1.4 NULL 値

このセクションでは、MySQL で文字列と数値を記述するさまざまな方法を説明します。 また、MySQL でこれらの基本データ型を処理する時に遭遇するであろう、さまざまなニュアンスと "了解事項" についても扱います。

6.1.1.1 文字列

文字列は、単一引用符 （`''）または二重引用符（`"'）で囲まれた文字の並び（シーケンス）です（ANSI モードでの実行時は引用符のみ）。次に例を示します。

'a string' "another string"

一部のシーケンスは、個々の文字列内で特別な意味を持ちます。これらのシーケンスは、いずれも、エスケープ文字として知られるバックスラッシュ（`\'）で始まります。MySQL では、次のエスケープシーケンスが認識されます。

\0

ASCII 0（NUL）文字。

\'

単一引用符（`''）。

\"

二重引用符（`"'）。

\b

バックスペース文字。

\n

改行文字(LF)。

\r

復帰改行文字(CR)。

\t

タブ文字。

\z

ASCII(26)（Control-Z）。この文字をコード化することによって、ASCII(26) が Windows では END-OF-FILE を表すという問題を回避することができる（ASCII(26) では、mysql database < filename を使用する場合に問題が発生する）。

\\

バックスラッシュ（`\'）文字。

\%

`%' 文字。これは、`%' をそのまま使用したときにワイルドカード文字として解釈されてしまうコンテキストで `%' 自体を検索する場合に使用する。 「6.3.2.1 文字列比較関数」 節 参照 。

\_

`_' 文字。これは、`_' をそのまま使用したときにワイルドカード文字として解釈されてしまうコンテキストで `_' 自体を検索する場合に使用する。 「6.3.2.1 文字列比較関数」 節 参照 。

文字列の一部のコンテキストでは、`\%' または `\_' を使用したときに、`%' と `_' の代わりに、文字列 `\%' と `\_' がそれぞれ返されることに注意してください。

文字列に引用符を含める方法は、いくつかあります。

• `'' で囲んだ文字列内で `'' を使用する場合、文字列内の `'' は `"' と記述することができる。

• `"' で囲んだ文字列内で `"' を使用する場合、文字列内の `"' は `""' と記述することができる。

• 引用符の直前にエスケープ文字（`\'）を使用することができる。

• `"' で囲んだ文字列内で `'' を使用する場合は、`'' を 2 つ続けて入力したり、エスケープしたりなどの特別な処置を行う必要はない。同様に、`'' で囲んだ文字列内で `"' を使用する場合も、特別扱いする必要はない。

次の SELECT ステートメントは、文字列の引用とエスケープが実際にどのように働くかを示しています。

mysql> SELECT 'hello', '"hello"', '""hello""', 'hel''lo', '\'hello'; +-------+---------+-----------+--------+--------+ | hello | "hello" | ""hello"" | hel'lo | 'hello | +-------+---------+-----------+--------+--------+ mysql> SELECT "hello", "'hello'", "''hello''", "hel""lo", "\"hello"; +-------+---------+-----------+--------+--------+ | hello | 'hello' | ''hello'' | hel"lo | "hello | +-------+---------+-----------+--------+--------+ mysql> SELECT "This\nIs\nFour\nlines"; +--------------------+ | This Is Four lines | +--------------------+

文字列のカラム（BLOB など）にバイナリデータを挿入する場合、次の文字はエスケープシーケンスを使って表現する必要があります。

NUL

ASCII 0。この文字は `\0' (バックスラッシュ + ASCII `0' 文字）で表現する。

\

ASCII 92、バックスラッシュ。`\\' として表現する。

'

ASCII 39、単一引用符。`\'' として表現する。

"

ASCII 34、二重引用符。`\"' として表現する。

C コードを書く場合は、INSERT ステートメントの文字をエスケープする目的で C API 関数 mysql_real_escape_string() を使用できます。 「11.1.2 C API 関数の概要」 節 参照 。Perl では、DBI パッケージの quote メソッドを使用して、特殊文字を適切なエスケープシーケンスに変換することができます。 「Perl DBI クラス」 節 参照 。

上記の特殊文字のいずれかが含まれている可能性がある文字列には、必ずエスケープ関数を使用するようにします。

または、MySQL API の多くのものが一種のプレースホルダ機能を備えているため、この機能を使ってクエリ文字列に特殊なマーカーを挿入し、クエリの発行時にデータ値をそれらのマーカーにバインドすることもできます。この場合、値内の特殊文字のエスケープ処理が API によって自動で行われます。

6.1.1.2 数値

整数は数字の列として表現されます。浮動小数点では、小数を区切るために `.' が使用されます。どちらの型の数値でも、先頭に `-' を付けることによって、負数を表すことができます。

有効な整数の例:

1221 0 -32

有効な浮動小数点数の例:

294.42 -32032.6809e+10 148.00

浮動小数点のコンテキストで整数を使用することもできます。この場合、整数は同等の浮動小数点数として解釈されます。

バージョン 4.1.0 以降、定数 TRUE は 1 として評価され、定数 FALSE は 0 として評価されます。

6.1.1.3 16 進値

MySQL では、16 進値をサポートしています。数値のコンテキストでは、16 進値は整数（64 ビット精度）のように動作します。文字列のコンテキストでは、16 進値はバイナリ文字列のように動作します。この場合、16 進数の各ペアが 1 文字に変換されます。

mysql> SELECT x'4D7953514C'; -> MySQL mysql> SELECT 0xa+0; -> 10 mysql> SELECT 0x5061756c; -> Paul

MySQL 4.1（および --new オプションを使用した MySQL 4.0）では、16 進値のデフォルトのデータ型は文字列です。16 進値の文字列が確実に数値として扱われるようにするには、その文字列に対して CAST( ... AS UNSIGNED) を使用します。

x'hexstring' 構文（4.0 の新機能）は標準 SQL に基づいており、0x 構文は ODBC に基づいています。16 進文字列は、BLOB カラムの値を提供する目的で、ODBC によって使用されることがよくあります。 文字列または数値を 16 進形式の文字列に変換するには、HEX() 関数を使用できます。

6.1.1.4 NULL 値

NULL 値は "データなし" を意味し、数値型での 0 や文字列型での空文字列などの値とは異なります。 「A.5.3 NULL 値の問題」 節 参照 。

テキストファイルのインポートまたはエクスポート形式（LOAD DATA INFILE、SELECT ... INTO OUTFILE）の使用時、NULL は \N で表現することができます。 「6.4.8 LOAD DATA INFILE 構文」 節 参照 。

6.1.2 データベース名、テーブル名、インデックス名、カラム名、エイリアス名

MySQL では、データベース名、テーブル名、インデックス名、およびエイリアス名には、すべて同じ規則が適用されます。

注意: 識別子（データベース名、テーブル名、カラム名）を ``' で引用する事ができます。MySQL バージョン 3.23.6 以降では、ANSI モードで実行した時は、`"' も識別子の引用処理に使用することができます。 「1.8.2 ANSI モードでの MySQL の実行」 節 参照 。

上記に補足して、ASCII(0)、ASCII(255)、および引用文字はいずれも識別子内では使用できないことに注意してください。

識別子が予約語である場合や、識別子に特殊文字が含まれている場合は、引用符として使用したバッククォート（「`」）文字でその識別子を必ず囲む必要があります。

mysql> SELECT * FROM `select` WHERE `select`.id > 100;

「6.1.7 MySQL での予約語の扱い」 節 参照 。

MAXDB または ANSI_QUOTES モードで MySQL を実行する場合は、識別子を囲む引用符として二重引用符も使用できます。

mysql> CREATE TABLE "test" (col INT); ERROR 1064: You have an error in your SQL syntax. (...) mysql> SET SQL_MODE="ANSI_QUOTES"; mysql> CREATE TABLE "test" (col INT); Query OK, 0 rows affected (0.00 sec)

「4.1.1 mysqld コマンドラインオプション」 節 参照 。

バージョン 3.23.6 より前の MySQL バージョン では、名前に関して次の規則が適用されます。

• 個々の名前は、現在のキャラクタセットに従った英数字、および `_' と `$' で構成することができる。デフォルトのキャラクタセットは ISO-8859-1 Latin1。このキャラクタセットは、 mysqld に --default-character-set オプションを指定することにより変更可能。 「4.7.1 データおよびソート用キャラクタセット」 節 参照 。

• 個々の名前では、名前に使用可能な任意の文字を、先頭文字とすることができる。先頭を数字にすることも可能（この点は、他の多くのデータベースシステムと異なる）。ただし、数字だけで構成される名前は使用できない。

• `.' 文字は名前には使用できない。この文字は、カラムを参照するための拡張形式で使用される（これについては後述する）。

1e のような名前は、使用しないでください。これは、1e+1 のような式があいまいになるためです。1e+1 は、式 1e + 1 として、または数値 1e+1 として解釈されます。

MySQL では、次の形式のいずれかを使用してカラムを参照することができます。

対象となる参照があいまいな場合、カラム参照の前に tbl_name や db_name.tbl_name を付ける必要があります。 たとえば、テーブル t1 と t2 のそれぞれに同名のカラム c があり、t1 と t2 の両方を使用する SELECT ステートメントで c を読み取るとします。この場合 c は、ステートメントで使用されている 2 つのテーブル中で一意なカラムを表すものではなく、あいまいであるため、t1.c または t2.c と記述することによって、どちらのテーブルが対象か指定する必要があります。同様に、データベース db1 のテーブル t とデータベース db2 のテーブル t に含まれているカラムを取り出す場合は、それぞれのテーブルのカラムを db1.t.col_name、db2.t.col_name として参照します。

構文 .tbl_name はカレントデータベースのテーブル tbl_name を意味します。この構文は ODBC との互換性を確保する目的で許容されています。これは、一部の ODBC プログラムでテーブル名の先頭に `.' 文字が付けられるためです。

6.1.3 名前におけるケース依存

MySQL において、データベースとテーブルは、ディレクトリとそれらのディレクトリ内のファイルに対応しています。そのため、ベースとなっているオペレーティングシステムで大文字と小文字が区別される場合（ケース依存）、データベース名とテーブル名でも大文字と小文字が区別されます。つまり、Windows ではデータベース名とテーブル名で大文字と小文字は区別されず、ほとんどの種類の Unix では大文字と小文字が区別されることになります。ただし、重要な例外が 1 つあります。Mac OS X でデフォルトの HFS+ ファイルシステムを使用している場合です。 しかし、Mac OS X は UFS ボリュームもサポートしています。UFS ボリュームでは Unix の場合と同じように Mac OS X でも大文字と小文字が区別されます。 「1.8.3 SQL-92 標準に対する MySQL 拡張機能」 節 参照 。

注意: Windows ではデータベース名とテーブル名で大文字と小文字は区別されませんが（ケース非依存）、同じクエリ内で異なるケースを使用して同じデータベースやテーブルを参照しないようにしてください。次のクエリでは、同じテーブルが my_table および MY_TABLE として参照されています。したがって、このクエリは機能しません。

mysql> SELECT * FROM my_table WHERE MY_TABLE.col=1;

カラム名とカラムのエイリアスは、あらゆる状況においてケース非依存です。

テーブルのエイリアスはケース依存です。次のクエリでは、同じエイリアスが a および A として参照されています。したがって、このクエリは機能しません。

mysql> SELECT col_name FROM tbl_name AS a -> WHERE a.col_name = 1 OR A.col_name = 2;

データベース名やテーブル名に大文字と小文字のどちらを使用したか覚えにくい場合は、データベースとテーブルは必ず小文字の名前で作成するなどの一貫した規則を設けるようにします。

この問題に対処する 1 つの方法は、mysqld の先頭に -O lower_case_table_names=1 を付けることです。このオプションのデフォルトは Windows では 1 で、Unix では 0 です。

lower_case_table_names が 1 の場合、MySQL では、保管およびルックアップ時にすべてのテーブル名が小文字に変換されます（バージョン 4.0.2 以降、このオプションはデータベース名にも適用されます。4.1.1 以降、このオプションはテーブルエイリアスにも適用されます）。

このオプションを変更する場合は、最初に元のテーブル名を小文字に変換してから mysqld を起動する必要があります。

MyISAM ファイルを Windows から Unix のディスクに移動した場合、`mysql_fix_extensions' ツールを使用して、指定した各データベースディレクトリ内のファイル拡張子のケース（小文字の `.frm'、大文字の `.MYI' および `.MYD'）を修正する必要がある場合があります `mysql_fix_extensions' は `scripts' サブディレクトリにあります。

6.1.4 ユーザ変数

MySQL では、@variablename 構文での接続ごとのユーザ変数をサポートしています。変数名は、現在のキャラクタセット内の英数字、および `_'、`$'、`.' で構成することができます。デフォルトのキャラクタセットは ISO-8859-1 Latin1 です。このキャラクタセットは、--default-character-set オプションを指定した mysqld で変更可能です。 「4.7.1 データおよびソート用キャラクタセット」 節 参照 。ユーザ変数名は、バージョン 5.0 以降のバージョンではケース非依存で、バージョン 5.0 より前のバージョンではケース依存です。

変数は初期化する必要はありません。変数の値はデフォルトでは NULL であり、整数、実数、または文字列値を格納することができます。スレッドのすべての変数は、そのスレッドが終了すると自動的に解放されます。

変数は SET 構文を使用して設定することができます。

SET @variable= { integer expression | real expression | string expression } [,@variable= ...].

SET 以外のステートメントで変数に値を代入することも可能です。 ただし、この場合、代入演算子は = ではなく := です。= は、SET 以外のステートメントにおいて、比較用に予約されています。

mysql> SET @t1=0, @t2=0, @t3=0; mysql> SELECT @t1:=(@t2:=1)+@t3:=4,@t1,@t2,@t3; +----------------------+------+------+------+ | @t1:=(@t2:=1)+@t3:=4 | @t1 | @t2 | @t3 | +----------------------+------+------+------+ | 5 | 5 | 1 | 4 | +----------------------+------+------+------+

ユーザ変数は、式を使用できる箇所に使用することができます。ただし、SELECT 文の LIMIT 節や LOAD DATA 文の IGNORE number LINES 節など、数値が明示的に要求されている文脈での使用は含まれません。

注意: SELECT 文においては、それぞれの式は、クライアントに送られた時にはじめて評価されます。したがって、HAVING、GROUP BY、ORDER BY 節において、SELECT 部に設定された変数を含む式を参照することはできません。たとえば、次の文は、期待どおりに機能しません。

mysql> SELECT (@aa:=id) AS a, (@aa+3) AS b FROM table_name HAVING b=5;

その理由は、@aa の値が現在のレコードの値ではなく、前に受け取ったレコードの id 値であるためです。

原則として、変数への値の代入と使用の両方の処理を、同じステートメントでは行わないでください。

変数の設定とその使用を同じステートメントで行った場合、変数のデフォルトの結果型がそのステートメントの開始時におけるその変数のデータ型に基づいて決まってしまう、という問題もあります（値が代入されていない変数は NULL 値を取り、STRING 型であると想定されます）。この例を次に示します。

mysql> SET @a="test"; mysql> SELECT @a,(@a:=20) FROM table_name;

この場合、MySQL では、カラム 1 が文字列としてクライアントに報告されます。そして、2 番目のレコードで @a が数値に設定されるにもかかわらず、@a へのすべてのアクセスが文字列に変換されます。ステートメントの実行後、@a は数値とみなされるようになります。

この場合、何か問題がある場合は、変数の設定とその使用を同じステートメントで行わないようにするか、もしくはその変数を使用する前に値を 0、0.0、または "" に設定するようにします。

6.1.5 システム変数

MySQL 4.0.3 以降では、多くのシステム変数や接続変数にアクセスしやすくなっています。それらの変数のほとんどは、サーバを停止することなく変更できます。

システム変数には、現在の接続だけに該当するスレッド固有（接続固有）変数と、グローバルイベントの設定に使用されるグローバル変数の 2 つの種類があります。 グローバル変数は、新しい接続に対応するスレッド固有変数の初期値を設定するためにも使用されます。

mysqld の起動時には、コマンドライン引数とオプションファイルからすべてのグローバル変数が初期化されます。この値は SET GLOBAL コマンドを使用して変更することができます。新しいスレッドが作成されると、グローバル変数からスレッド固有変数が初期化されます。この値は新しい SET GLOBAL コマンドを発行しても変更されません。

GLOBAL 変数の値を設定するには、次の構文のいずれかを使用します（ここでは、変数の例として sort_buffer_size を使用します）。

SET GLOBAL sort_buffer_size=value; SET @@global.sort_buffer_size=value;

SESSION 変数の値を設定するには、次の構文のいずれかを使用することができます。

SET SESSION sort_buffer_size=value; SET @@session.sort_buffer_size=value; SET sort_buffer_size=value;

GLOBAL と SESSION のどちらも指定しないと、SESSION が使用されます。 「5.5.6 SET 構文」 節 参照 。

LOCAL は SESSION のシノニムです。

GLOBAL 変数の値を取り出すには、次のコマンドのいずれかを使用することができます。

SELECT @@global.sort_buffer_size; SHOW GLOBAL VARIABLES like 'sort_buffer_size';

SESSION 変数の値を取り出すには、次のコマンドのいずれかを使用することができます。

SELECT @@session.sort_buffer_size; SHOW SESSION VARIABLES like 'sort_buffer_size';

@@variable_name 構文で変数を取り出すときに GLOBAL と SESSION のどちらも指定しないと、MySQL では、スレッド固有（SESSION）の値がある場合は、その値が返されます。スレッド固有の値がない場合は、グローバル値が返されます。

GLOBAL の値しか存在しない変数の場合、取り出しには GLOBAL と指定する必要はありませんが、設定には GLOBAL と指定する必要があります。これは、後から、同名のスレッド固有変数を導入したり、削除したりするときに問題が発生しないようにするためです。この場合、自分の接続だけでなく、サーバの状態そのものを誤って変更してしまう可能性があります。

次の一覧に、変更および取り出し対象となるすべての変数と、それらの変数で GLOBAL と SESSION のどちらを使用できるかを示します。

値のデータ型が num となっている変数には、数値を設定することができます。 bool となっている変数には、0、1、ON、または OFF を設定することができます。 enum 型の変数には、通常、その変数に対して利用可能な値の 1 つを設定できますが、該当の enum（列挙）値に対応する数値を設定することもできます（最初の列挙値は 0 です）。

これらの変数のいくつかについて説明します。

その他の変数については、スタートアップオプション、SHOW VARIABLES、および SET に関するセクションで説明しています。 「4.1.1 mysqld コマンドラインオプション」 節 参照 。 「4.6.8.4 SHOW VARIABLES」 節 参照 。 「5.5.6 SET 構文」 節 参照 。

6.1.6 コメント構文

MySQL サーバでは、コメントスタイルとして、#（行末まで）、--（行末まで）、および /*（行中または複数行）*/をサポートしています。

mysql> SELECT 1+1; # このコメントは行末まで続く mysql> SELECT 1+1; -- このコメントは行末まで続く mysql> SELECT 1 /* これは行中コメント */ + 1; mysql> SELECT 1+ /* これは 複数行コメント */ 1;

--（ダッシュ2つ）のコメントスタイルでは、2 つ目のダッシュの後にスペースを 1 つ以上挿入する必要があることに注意してください。

サーバは上記のコメント構文を理解しますが、mysql クライアントでの /* ... */ コメントの解析には一定の制約があります。

• 単一引用符と二重引用符は、コメント内であっても、引用文字列の開始を示すものとして解釈される。そのコメント内に、最初の引用符と一致するもう 1 つの引用符がない場合、パーサはそのコメントの終了を認識しない。mysql を対話的に実行している場合は、プロンプトが mysql> から '> または "> に変わるため、パーサがコメントの終了を認識できずにいることがわかる。

• セミコロンは、現在の SQL ステートメントの終了を表すものとして解釈され、セミコロンの後は、次のステートメントの開始を表すものとして解釈される。

これらの制約は、mysql を対話的に実行する場合と、mysql < some-fileを使用して、コマンドを格納したファイルから入力を読み取るよう mysql に指示する場合の両方に適用されます。

2 つ目のダッシュの後にスペースが 1 つもない場合、SQL-99 のコメントスタイル `--' は MySQL で有効とされません。 「1.8.4.7 コメントの開始記号としての `--'」 節 参照 。

6.1.7 MySQL での予約語の扱い

一般的な問題の 1 つとして、TIMESTAMP や GROUP など、MySQL に組み込まれているデータ型や関数の名前を使用するカラム名を含むテーブルの作成に関連する問題があります。このようなカラム名を含むテーブルの作成は可能です（たとえば、ABS はカラム名として使用可能です）。しかし、デフォルトでは、関数の呼び出し時に、関数名とそれに続く `(' 文字との間に空白を挿入することはできません。これは、関数呼び出しをカラム名の参照と区別するためです。

--ansi または --sql-mode=IGNORE_SPACE オプションを指定してサーバを起動した場合は、関数呼び出しで、関数名とそれに続く `(' 文字との間に空白を挿入することができます。これらのオプションを指定すると、関数名が予約語として扱われるようになります。そのため、関数名と同一のカラム名は、 「6.1.2 データベース名、テーブル名、インデックス名、カラム名、エイリアス名」 で説明しているように引用符で囲む必要があります。

以下の語は MySQL において明示的に予約されています。これらの語のほとんど（たとえば、GROUP）は、SQL-92 では、カラム名またはテーブル名としての使用を禁止されています。 いくつかの語は、MySQL でそれらの語を必要とし、（現在）MySQL で yacc パーサが使用されていることから予約されています。

以下のシンボル（上の表に含まれるもの)は SQL-99 では使用を禁止されていますが、MySQL ではカラム名またはテーブル名として使用可能です。これは、それらの名前がごく一般的なものであり、多くの人々にすでに使用されているためです。

• ACTION
• BIT
• DATE
• ENUM
• NO
• TEXT
• TIME
• TIMESTAMP

6.2 カラム型

MySQL では、複数のカラム型をサポートしています。これらのカラム型は、数値型、日付と時刻型、文字列（文字）型の 3 つのカテゴリに分類することができます。このセクションでは、まず、使用できるカラム型の概要を示し、各カラム型で必要となる記憶容量について簡単に説明します。その後、各カテゴリのカラム型の特性を詳しく説明します。 概要はあえて簡単にまとめてあります。値の有効な指定形式など、個々のカラム型の追加情報については、それぞれの詳細な説明を参照してください。

以下に、MySQL でサポートしているカラム型を示します。 説明内では、次のコード文字を使用します。

M

最大表示サイズを表す。正式な最大表示サイズは 255。

D

小数点型に適用され、小数点以下の桁数を表す。最大値は 30 だが、M-2 より大きくしないようにする。

角かっこ（`[' と `]'）は、オプションの型指定子の一部であることを表します。

カラムに対して ZEROFILL を指定すると、そのカラムに UNSIGNED 属性が自動で追加されることに注意してください。

警告: 整数値の減算で、どちらか一方の整数値が UNSIGNED 型の場合、結果の値は符号なしになります。 「6.3.5 キャスト関数」 節 参照 。

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

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

BIT

BOOL

BOOLEAN

いずれも TINYINT(1) のシノニム。 シノニム BOOLEAN はバージョン 4.1.0 で追加された。

ブール型の完全な処理は SQL-99 に基づいて導入される。

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 型のカラムに関しては、次の点について注意すること。

• すべての算術演算は符号付き BIGINT または DOUBLE 型の値を使って行われる。そのため、9223372036854775807（63 ビット）を超える、符号なしの大きい整数は、ビット関数以外では使用しないようにする。ビット関数以外でこのような大きい整数を使用すると、BIGINT から DOUBLE への変換時に発生する丸め誤差の影響で、結果の最後の桁の一部に誤りが出る場合がある。

  次の場合、SQL 4.0 では BIGINT を処理できる。

  • 整数を使って、符号なしの大きい値を BIGINT カラムに格納する場合
  • MIN(big_int_column) および MAX(big_int_column) において
  • 演算子（+、-、* など）の使用時に両方のオペランドが整数の場合

• 文字列として格納すれば、正確な整数値を BIGINT カラムに常に格納することができる。この場合、倍精度表現を介在しない、文字列から数値への変換が実行される。
• `-'、`+'、および `*' で両方の引数が整数値のときは、BIGINT 演算が使用される。したがって、2 つの大きな整数（または整数を返す関数の結果）を掛け算する場合、結果が 9223372036854775807 より大きいと、予期しない結果が返される場合がある。

FLOAT(precision) [UNSIGNED] [ZEROFILL]

浮動小数点数。precision は、単精度浮動小数点数の場合は <=24 で、倍精度浮動小数点数の場合は 25 〜 53 の間。これらの型はこのすぐ後に説明する FLOAT 型と DOUBLE 型に類似している。 FLOAT(X) は対応する FLOAT 型および DOUBLE 型と範囲は同じだが、表示サイズと小数部桁数は定義されない。

MySQL バージョン 3.23 では、これは真の浮動小数点値。それ以前の MySQL バージョンでは、FLOAT(precision) の小数部は常に 2 桁になる。

MySQL の計算はすべて倍精度で行われるため、FLOAT の使用時には予期しない問題が発生する場合があることに注意する。 「A.5.6 不整合レコードの問題解決」 節 参照 。

この構文は ODBC との互換性を確保するために提供されている。

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

単精度浮動小数点数。使用可能な値は -3.402823466E+38 〜 -1.175494351E-38、0、および 1.175494351E-38 〜 3.402823466E+38。UNSIGNED を指定した場合、負数は使用できない。M は表示幅で、D は小数部桁数。引数のない FLOAT や、X が 24 以下の FLOAT(X) は、単精度浮動小数点数を表す。

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

倍精度浮動小数点数。 使用可能な値は -1.7976931348623157E+308 〜 -2.2250738585072014E-308、0、および 2.2250738585072014E-308 〜 1.7976931348623157E+308。UNSIGNED を指定した場合、負数は使用できない。M は表示幅で、D は小数部桁数。引数のない DOUBLE や、X が 25 以上 53 以下である FLOAT(X) は、倍精度浮動小数点数を表す。

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

REAL[(M,D)] [UNSIGNED] [ZEROFILL]

いずれも DOUBLE のシノニム。

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

アンパック浮動小数点数。CHAR カラムのように動作する。"アンパック" とは、その数値が、各桁に 1 文字ずつ使用して文字列として格納されることを意味する。M では、小数点と、負数に使用される `-' 記号はカウントされない（しかし、これらのためのスペースは確保される）。D が 0 の場合、値は小数点も小数部も持たない。DECIMAL 値の最大範囲は、DOUBLE と同じだが、個々の DECIMAL カラムの実際の範囲は、M と D の値によって制限される。UNSIGNED を指定した場合、負数は使用できない。

D を省略した場合、デフォルトは 0。M を省略した場合、デフォルトは 10。

MySQL バージョン 3.23 より前のバージョンでは、M 引数に、符号と小数点に必要なスペースを含める必要がある。

DEC[(M[,D])] [UNSIGNED] [ZEROFILL]

NUMERIC[(M[,D])] [UNSIGNED] [ZEROFILL]

FIXED[(M[,D])] [UNSIGNED] [ZEROFILL]

いずれも DECIMAL のシノニム。

FIXED エイリアスは、他のサーバとの互換性を確保する目的で、バージョン 4.1.0 で追加された。

DATE

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

DATETIME

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

TIMESTAMP[(M)]

タイムスタンプ。範囲は '1970-01-01 00:00:00' 〜 2037 年の一定の時点。

MySQL 4.0 以前のバージョンでは、TIMESTAMP 値は、M が 14（または指定なし）、12、8、または 6 のどれであるかに応じて、YYYYMMDDHHMMSS、YYMMDDHHMMSS、YYYYMMDD、または YYMMDD 形式で表示されるが、TIMESTAMP カラムへの値の割り当てには文字列または数値のいずれかを使用することができる。

MySQL 4.1 以降では、TIMESTAMP は 'YYYY-MM-DD HH:MM:SS' 形式の文字列として返される。数値として返されるようにするには、タイムスタンプカラムに +0 を追加する。異なるタイムスタンプ長はサポートしていない。バージョン 4.0.12 以降、--new オプションを使用することで、バージョン 4.1 と同じようにサーバを動作させることができる。

TIMESTAMP カラムに値を指定しないと、最後に行われた操作の日付と時刻が自動的に設定されるため、このカラムは INSERT 操作や UPDATE 操作の日付と時刻を記録するのに役立つ。また、このカラムに NULL 値を割り当てることによって、現在の日付と時刻をカラムに設定することができる。 「6.2.2 日付と時刻型」 節 参照 。

M 引数は、TIMESTAMP カラムの表示方法にのみ作用する。 この値は常に 4 バイトで格納される。

M が 8 または 14 の TIMESTAMP(M) カラムは数値として報告され、その他の TIMESTAMP(M) カラムは文字列として報告されることに注意する。これは単に、これらのデータ型のテーブルのダンプとリストアを確実に実行できるようにすることを目的としている。 「6.2.2.2 DATETIME、DATE、TIMESTAMP 型」 節 参照 。

TIME

時刻。範囲は '-838:59:59' 〜 '838:59:59'。 MySQL では、TIME 値は 'HH:MM:SS' 形式で表示されるが、TIME カラムへの値の割り当てには文字列または数値のいずれかを使用することができる。 「6.2.2.3 TIME 型」 節 参照 。

YEAR[(2|4)]

2 桁または 4 桁の形式の年（デフォルトは 4 桁）。使用可能な値は、4 桁形式では 1901 〜 2155 と 0000、2 桁形式では 1970 〜 2069（70 〜 69）。MySQL では、YEAR 値は YYYY 形式で表示されるが、YEAR カラムへの値の割り当てには文字列または数値のいずれかを使用することができる（YEAR 型は MySQL バージョン 3.22 より前のバージョンでは使用できない）。 「6.2.2.4 YEAR 型」 節 参照 。

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

固定長の文字列。格納時には、指定の長さになるよう、右側にスペースが埋め込まれる。M の範囲は 0 〜 255 文字（3.23 より前の MySQL バージョンでは 1 〜 255）。 値の取り出し時には、後続のスペースが削除される。BINARY キーワードを指定しない場合、CHAR 型の値のソートと比較は、デフォルトのキャラクタセットに基づいてケース非依存方式で行われる。

バージョン 4.1.0 以降では、255 より大きい M 値を指定すると、カラム型が TEXT 型に変換される。

これは互換性を考慮した機能。

NATIONAL CHAR（または、これに対応する短縮形式 NCHAR）は、SQL-99 における、CHAR カラムでデフォルトの CHARACTER セットを使用することを定義する方法。MySQL では、これはデフォルト。

CHAR は CHARACTER の省略形。

バージョン 4.1.0 以降では、latin1 キャラクタセットを CHAR カラムに割り当てる ASCII 属性を指定することができる。

バージョン 4.1.1 以降では、ucs2 キャラクタセットを CHAR カラムに割り当てる UNICODE 属性を指定することができる。

MySQL では、CHAR(0) 型のカラムを作成することができる。これは、主に、カラム自体は必要とするが、そのカラムの値を実際に使用することはない、というような古いアプリケーションに対応する必要があるときに役立つ。また、2 つの値しか取らないカラムが必要な場合にも非常に役立つ。 CHAR(0) は NOT NULL としては定義されず、1 ビットのみ占め、NULL または "" の 2 つの値しか取らない。 「6.2.3.1 CHAR 型と VARCHAR 型」 節 参照 。

CHAR

CHAR(1) のシノニム。

[NATIONAL] VARCHAR(M) [BINARY]

可変長文字列。注意: 後続のスペースは値の格納時に削除される（これは SQL-99 の仕様とは異なる）。M の範囲は 0 〜 255 文字（MySQL バージョン 4.0.2 では 1 〜 255）。 BINARY キーワードを指定しないと、VARCHAR 値のソートと比較は、ケース非依存方式で行われる。 「6.5.3.1 カラムの暗黙的な変更」 節 参照 。

バージョン 4.1.0 以降では、255 より大きい M 値を指定すると、カラム型が TEXT 型に変換される。 これは互換性を考慮した機能。

VARCHAR は CHARACTER VARYING の省略形。 「6.2.3.1 CHAR 型と VARCHAR 型」 節 参照 。

TINYBLOB

TINYTEXT

最大長が 255（2^8 - 1）文字の BLOB 型または TEXT 型のカラム。 「6.5.3.1 カラムの暗黙的な変更」 節 参照 。 「6.2.3.2 BLOB 型と TEXT 型」 節 参照 。

BLOB

TEXT

最大長が 65535（2^16 - 1）文字の BLOB 型または TEXT 型のカラム。 「6.5.3.1 カラムの暗黙的な変更」 節 参照 。 「6.2.3.2 BLOB 型と TEXT 型」 節 参照 。

MEDIUMBLOB

MEDIUMTEXT

最大長が 16777215（2^24 - 1）文字の BLOB 型または TEXT 型のカラム。 「6.5.3.1 カラムの暗黙的な変更」 節 参照 。 「6.2.3.2 BLOB 型と TEXT 型」 節 参照 。

LONGBLOB

LONGTEXT

最大長が 4294967295 または 4G（2^32 - 1）バイトの BLOB 型または TEXT 型のカラム。 「6.5.3.1 カラムの暗黙的な変更」 節 参照 。 MySQL バージョン 3.23 まで、サーバ/クライアントプロトコルおよび MyISAM テーブルでは、通信パケットまたはテーブルレコードごとに 16M の制約があった。バージョン 4.x 以降、LONGTEXT 型または LONGBLOB 型のカラムで許容される最大長は、クライアント/サーバプロトコル間の通信バッファおよび使用可能なメモリ量にしたがって調整された最大パケットサイズによって決まる。 「6.2.3.2 BLOB 型と TEXT 型」 節 参照 。

ENUM('value1','value2',...)

列挙。値のリスト 'value1'、'value2'、...、NULL または特殊な "" エラー値から選択された、1 つの値のみ持つことができる文字列オブジェクト。ENUM には最大 65535 の重複のない値を組み込むことができる。 「6.2.3.3 ENUM 型」 節 参照 。

SET('value1','value2',...)

セット。0 個以上の値を持つことができる文字列オブジェクト。これらの値はいずれも値のリスト 'value1', 'value2', ... から選択する必要がある。1 つの SET には、最大 64 個の要素を組み込むことができる。 「6.2.3.4 SET 型」 節 参照 。

6.2.1 数値型
6.2.2 日付と時刻型
6.2.3 文字列型
6.2.4 正しいカラム型の選択
6.2.5 他のデータベースエンジンのカラム型の使用
6.2.6 各カラム型に必要な記憶容量

6.2.1 数値型

MySQL では、SQL-92 のすべての数値データ型をサポートしています。これらのデータ型は、正確な数値データ型（NUMERIC、DECIMAL、INTEGER、SMALLINT）だけでなく、近似数値データ型（FLOAT、REAL、DOUBLE PRECISION）を含みます。キーワード INT は INTEGER のシノニムで、キーワード DEC は DECIMAL のシノニムです。

MySQL では、NUMERIC 型と DECIMAL 型は、SQL-92 標準で使用可能なデータ型と同じデータ型として実装されます。これらのデータ型は、金額データに関する値など、正確な精度で保存することが重要となる値に対して使用されます。これらのいずれかの型のカラムを宣言する際には、次のように、精度とスケールを指定することができます（通常、これらが指定されます）。

salary DECIMAL(5,2)

この例で、5 (precision) は、値に対して格納される 10 進数の桁数を表わし、2 (scale) は、小数点に続いて格納される桁数を表わします。したがって、この場合、salary カラムに格納できる値の範囲は、-99.99 〜 99.99 になります（MySQL では、正数の符号を格納する必要がないため、このカラムには、実際には、999.99 までの数値を格納することができます）。

SQL-92 では、構文 DECIMAL(p) は DECIMAL(p,0) と同じです。同様に、構文 DECIMAL は DECIMAL(p,0) と同じです。この場合、p の値を決定する実装を行うことができます。MySQL では、現在のところ、DECIMAL および NUMERIC データ型のこれらの異型をサポートしていません。通常、これらの型の主な利点は精度とスケールを明示的に制御できることによるため、これはそれほど問題にはなりません。

DECIMAL 値と NUMERIC 値は、値の小数部の精度を維持するため、バイナリの浮動小数点数としてではなく、文字列として格納されます。値の各桁、小数点（scale > 0 の場合）、そして `-' 符号（負数の場合）に対して、1 文字が使用されます。scale が 0 の場合、DECIMAL 値と NUMERIC 値には小数点も小数部も含まれません。

DECIMAL 値と NUMERIC 値の最大範囲は DOUBLE 値と同じですが、個々の DECIMAL または NUMERIC カラムの実際の範囲は、個々のカラムの precision または scale によって制限されます。指定されている scale で許容される桁数を超える桁数を小数部に持つ値がカラムに割り当てられた場合、値は指定されている scale に合わせて丸められます。指定されている（またはデフォルトの）precision と scale によって暗黙的に指定された範囲を超える大きさの値が DECIMAL または NUMERIC カラムに割り当てられた場合、その範囲の最大値が格納されます。

SQL-92 標準の拡張として、MySQL では、前出の表に挙げているように、TINYINT、MEDIUMINT、および BIGINT 型もサポートしています。もう 1 つの拡張として、MySQL には、INT(4) のように、型の基本キーワードに続いて整数値の表示幅をかっこ内に指定できるオプションがあります。このオプションの表示幅の指定は、カラムに指定された幅より小さい幅を持つ値で表示の左側を埋める目的で使用されますが、そのカラムに格納できる値の範囲が制限されたり、そのカラムに指定された幅を超える幅を持つ値の桁数が制限されたりすることはありません。オプションの拡張属性 ZEROFILL と組み合せて使用した場合、デフォルトのスペースに代わってゼロが埋め込まれます。 たとえば、INT(5) ZEROFILL として宣言されたカラムの場合、値 4 は 00004 として取り出されます。注意: 整数カラムの表示幅より大きい値を格納すると、MySQL で一部の複雑な結合のテンポラリテーブルを生成するときに問題が発生することがあります。この場合、データはあくまでも本来のカラム幅に合っているものとして扱われます。

すべての整数型には、オプション（非標準）属性 UNSIGNED を設定することができます。符号なしの値は、正数値だけを入力できるようにしたいカラムで、やや大きい数値範囲を必要とする場合に使用することができます。

MySQL 4.0.2 以降では、浮動小数点型にも UNSIGNED を設定することができます。 この属性が指定されていると、整数型の場合と同じように、カラムに負数の値を格納できなくなりますが、整数型とは異なり、カラム値の上の範囲は変わりません。

FLOAT 型は近似数値データ型を表現する目的で使用されます。 SQL-92 標準では、キーワード FLOAT に続くかっこ内にオプションの精度をビットで指定することができます（指数の範囲は指定できません）。このオプションの精度指定は MySQL 実装でもサポートしています。精度を指定しないでカラムに対して FLOAT キーワードを使用した場合、MySQL では 4 バイトを使って値が格納されます。FLOAT キーワードに続けてかっこ内に 2 つの数字を指定する可変の構文も使用できます。このオプションでは、最初の数字は値に必要なバイト単位の記憶容量を表わし、2 番目の数字は格納および表示する小数部の桁数を表わします（DECIMAL および NUMERIC と同様）。MySQL では、カラムに対して指定されている小数部桁数を超える数の桁を格納しようとすると、格納時に値が丸められ、余分な桁が削除されます。

REAL 型と DOUBLE PRECISION 型では精度の指定は行えません。SQL-92 標準の拡張として、MySQL では、DOUBLE 型は DOUBLE PRECISION 型のシノニムとして認識されます。SQL-92 標準では、REAL 型の精度は DOUBLE PRECISION 型で使用されている精度より小さくなければならないのに対し、MySQL では、これらの両方が 8 バイトの倍精度浮動小数点値として実装されます（非 "ANSI モード" で実行した場合）。 最大限の移植性を確保するためには、近似数値データ値の格納を必要とするコードでは、FLOAT または DOUBLE PRECISION の使用時に精度と小数部の桁数をいずれも指定しないようにします。

数値型のカラムに、そのカラム型で許容されている範囲を超える値を格納しようとすると、MySQL では、値は許容範囲の最大値または最低値に丸められて格納されます。

たとえば、INT カラムの範囲は -2147483648 から 2147483647 です。この場合、INT カラムに -9999999999 という値を挿入しようとすると、値は範囲の最低値に丸められ、-2147483648 として格納されます。同様に、9999999999 という値を挿入しようとすると、値は 2147483647 として格納されます。

INT カラムが UNSIGNED として設定されている場合、このカラムの範囲のサイズは変わりませんが、最小値と最大値はそれぞれ 0 と 4294967295 になります。 したがって、-9999999999 および 9999999999 という値を格納しようとすると、このカラムにはそれぞれ 0 および 4294967296 という値が格納されます。

ALTER TABLE、LOAD DATA INFILE、UPDATE、および複数行の INSERT ステートメントでは、切り落としによる値の変換は "警告" として報告されます。

6.2.2 日付と時刻型

6.2.2.1 西暦 2000 年問題と日付型
6.2.2.2 DATETIME、DATE、TIMESTAMP 型
6.2.2.3 TIME 型
6.2.2.4 YEAR 型

日付と時刻型には、DATETIME、DATE、TIMESTAMP、TIME、YEAR があります。これらの型のカラムは、いずれも、一定の範囲の正しい値を取りますが、その他に、実際には不正な値を指定するときに使用される "ゼロ" の値も取ります。MySQL では、'厳密' には正しくない一部の日付値（1999-11-31 など）も格納可能であることに注意してください。 これは、日付チェックはアプリケーションで実行されるので SQL サーバ側で行う必要はない、という前提に立っているためです。日付チェックを '迅速' に行うために、MySQL では、指定された月が 0 〜 12 の範囲にあるかどうかと、指定された日付が 0 〜 31 の範囲にあるかどうかのみチェックします。これらの範囲に 0 が含まれている理由は、MySQL では、DATE または DATETIME カラムの日の値または月日の値がゼロである日付の格納が許容されているためです。これは、誕生日を格納する必要があるアプリケーションで正確な日付がわからないときなどに非常に役立ちます。この場合、単に 1999-00-00 や 1999-01-00 などとして、日付を格納します（このような日付を指定した場合、DATE_SUB() や DATE_ADD などの関数によって正しい値が返ると想定することはできません）。

以下に、日付と時刻型に関して留意すべき一般考慮事項をいくつか示します。

• MySQL では、個々の日付または時刻型の値の取り出しは標準形式で行われるが、入力した値（たとえば、日付または時刻型に割り当てる値、またはこれらの型と比較する値の指定時など）については、さまざまな形式で解釈が試みられる。ただし、サポートしている形式は、以降のセクションで説明している形式に限られる。正しい値を指定することが前提となるため、非サポート形式で値を指定すると、予測できない結果が発生する場合がある。

• MySQL では、値の解釈が複数の形式で試みられるが、日付値の年部分は必ず左端と想定される。日付は、年-月-日の順序（例: '98-09-04'）で指定する必要がある。一般に使用されている月-日-年や日-月-年の順序（例: '09-04-98'、'04-09-98'）は使用しない。

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

• MySQL では、日付または時刻型で範囲外の値や不正な値（このセクションの最初の部分を参照）を入力すると、値はその型の "ゼロ" 値に変換される（この例外として、範囲外の TIME 値は TIME 型の範囲の最大値または最小値に切り落とされる）。次の表に、それぞれの型の "ゼロ" 値を示す。

  カラム型	"ゼロ" 値
  DATETIME	'0000-00-00 00:00:00'
  DATE	'0000-00-00'
  TIMESTAMP	00000000000000（長さは表示サイズに依存）
  TIME	'00:00:00'
  YEAR	0000

• "ゼロ" 値は特殊な値だが、上の表に示した値を使用することによって、"ゼロ" 値を明示的に格納または参照することができる。また、この他に、より簡単に記述できる値 '0' または 0 も、"ゼロ" 値の格納または参照に使用できる。

• ODBC では、日付または時刻型の値 "ゼロ" を処理できないため、MyODBC バージョン 2.50.12 以降では、MyODBC を通して日付または時刻型の値 "ゼロ" を使用すると、自動的に NULL に変換される。

6.2.2.1 西暦 2000 年問題と日付型

MySQL 自体は西暦 2000 年問題に対応していますが（ 「1.2.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 桁の YEAR/DATE/DATETIME 型が正しくソートされます。

一部の関数（MIN() や MAX()など）では、TIMESTAMP/DATE 型の値が数値に変換されることに注意してください。したがって、2 桁の年を持つタイムスタンプはこれらの関数では正常に機能しません。この場合の修正方法としては、TIMESTAMP/DATE を 4 桁の年形式に変換するか、または MIN(DATE_ADD(timestamp,INTERVAL 0 DAYS)) のようなものを使用します。

6.2.2.2 DATETIME、DATE、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 では、DATE 型の値の取り出しと表示は 'YYYY-MM-DD' 形式で行われます。サポートしている範囲は、'1000-01-01' 〜 '9999-12-31' です。

TIMESTAMP カラム型の特性と動作は、MySQL のバージョンとサーバでの SQL 実行モードに応じて異なります。

MAXDB モードでの実行時の TIMESTAMP の動作

MySQL を MAXDB モードで実行している場合、TIMESTAMP は DATETIME と同じように動作します。TIMESTAMP カラムの自動更新（次の段落で説明）は行われません。MySQL の MAXDB モードでの実行は、バージョン 4.1.1 以降で可能です。 「4.1.1 mysqld コマンドラインオプション」 節 参照 。

MAXDB モードで実行していないときの TIMESTAMP の動作

TIMESTAMP カラム型では、INSERT または UPDATE 操作に対して現在の日付と時刻を自動的に指定することができます。TIMESTAMP カラムが複数ある場合は、最初のカラムのみが自動で更新されます。

最初の TIMESTAMP カラムの自動更新は、次のいずれかの条件で発生します。

• INSERT または LOAD DATA INFILE ステートメントで、カラムが明示的に指定されていない場合。
• UPDATE ステートメントおよびその他の何らかのカラム変更値でカラムが明示的に指定されていない場合（注意: カラムにすでに設定されている値を設定しようとする UPDATE では、TIMESTAMP カラムは更新されない。カラムに現在の値を設定しようとしても、MySQL では、効率性を考慮して更新操作が無視される）。
• TIMESTAMP カラムに値 NULL が明示的に設定された場合。

2 番目以降の TIMESTAMP カラムにも、現在の日付と時刻を設定することができます。カラムに NULL または NOW() を設定します。

TIMESTAMP 型のいずれかのカラムに現在の日付と時刻以外の値を設定するには、そのカラムに対して、必要な値を明示的に設定します。これは、最初の TIMESTAMP カラムについても同様です。この特性は、次に示すように、レコードの作成時に TIMESTAMP カラムに現在の日時を設定し、その後そのレコードの更新時には設定済の値を変更しないようにする場合などに役立ちます。

• レコードの作成時に、MySQL によってカラムを設定する。 それにより、そのカラムが現在の日付と時刻に初期化される。

• そのレコードの他のカラムに対して後続の更新を行ったときには、TIMESTAMP カラムにそのカラムの現在の値を明示的に設定する。

とはいえ、DATETIME カラムを使用してレコードの作成時に値を NOW() に初期化し、後続の更新時にはそのままにしておくというのも、手軽な方法です。

MAXDB モードでの実行時の TIMESTAMP の特性

MySQL を MAXDB モードで実行している場合、TIMESTAMP は DATETIME とまったく変わりません。格納と表示には同じ形式が使用され、また値の範囲も同じです。MySQL の MAXDB モードでの実行は、バージョン 4.1.1 以降で可能です。 「4.1.1 mysqld コマンドラインオプション」 節 参照 。

MAXDB モードで実行していないときの、MySQL 4.1 以降での TIMESTAMP の特性

MySQL 4.1.0 では、TIMESTAMP カラムの格納および表示には、 DATETIME カラムと同じ形式が使用されます。したがって、次の段落で説明している方法で狭くしたり、広げたりすることはできません。つまり、TIMESTAMP(2) や TIMESTAMP(4) などは使用できないことになります。それ以外の特性は、以前の MySQL バージョンと同じです。

MySQL 4.1 より前のバージョンにおける TIMESTAMP の特性

TIMESTAMP 値は 1970 年の始まりから 2037 年の一定の時点までを範囲とし、時間分解能は 1 秒です。値は数値として表示されます。

MySQL で TIMESTAMP 型の値の取り出しと表示に使用される形式は、次の表に示すように、表示サイズによって異なります。最長の TIMESTAMP 形式は 14 桁ですが、TIMESTAMP 型のカラムはもっと短い表示サイズで作成することもできます。

TIMESTAMP 型のカラムでは、表示サイズにかかわらず、格納サイズはすべて同じです。最も一般的な表示サイズは 6、8、12、14 です。テーブルの作成時に任意の表示サイズを指定できますが、値 0 と 14 を超える値は強制的に 14 に設定されます。1 〜 13 の奇数値のサイズは強制的にすぐ上の偶数に設定されます。

注意: バージョン 4.1 以降、TIMESTAMP は 'YYYY-MM-DD HH:MM:SS' 形式の文字列として返されます。その他のタイムスタンプ長のサポートは中止されました。

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' として解釈される。

• DATETIME、DATE、または TIMESTAMP 型のコンテキストで許容される値を返す、NOW() や CURRENT_DATE などの関数の結果として指定。

不適切な 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 桁の長さにすると、YYYYMMDD または YYYYMMDDHHMMSS 形式であり、最初の 4 桁が年であると想定されます。数値を 6 桁または 12 桁の長さにすると、YYMMDD または YYMMDDHHMMSS 形式であり、最初の 2 桁が年であると想定されます。これら以外の長さの数値は、最も近い長さになるよう先頭にゼロが追加された数値として解釈されます。

区切りなしの文字列として指定した値は、その文字列の長さに基づいて解釈されます。文字列が 8 文字または 14 文字の場合、最初の 4 文字が年であると想定されます。それ以外の長さの文字列の場合、最初の 2 文字が年であると解釈されます。文字列は、それに含まれている各部分に対応して、左から右に、年、月、日、時、分、秒の値として解釈されます。したがって、6 文字より少ない文字列は使用できません。たとえば、1999 年 3 月を表わす値として '9903' を指定すると、MySQL では、テーブルに日付値として "ゼロ" が格納されます。これは、年と月の値が 99 と 03 として指定されていても日の部分がまったくないことから、正しい日付ではないためです。しかし、MySQL 3.23 以降では、欠落している月または日の部分を表わすゼロの値を明示的に指定することができます。たとえば、'990300' と指定することで、'1999-03-00' という日付値を格納することができます。

TIMESTAMP カラムでは、正しい値は、表示サイズにかかわらず、その値が指定されたときの完全な精度で格納されます。このことは、暗黙的に次のことを意味します。

• カラム型が TIMESTAMP(4) または TIMESTAMP(2) の場合でも、必ず年、月、日を指定する必要がある。このすべてを指定しないと、値は正しい日付とはならず、0 が格納される。

• ALTER TABLE を使用して表示桁数の小さな TIMESTAMP カラムの桁数を広げると、それまで "非表示" になっていた情報が表示される。

• 同様に、TIMESTAMP カラムを狭くしても、単に、値を表示したときに表示される情報が少なくなるだけで、情報自体が失われるわけではない。

• TIMESTAMP 型の値は完全な精度で格納されるが、基盤の格納値に対して直接作用する関数は UNIX_TIMESTAMP() だけである。他の関数は、取り出され、形式設定された値に作用する。したがって、HOUR() や SECOND() などの関数は、形式設定された値に TIMESTAMP 値の該当の部分が含まれていない場合、使用できない。たとえば、TIMESTAMP カラムの HH 部分は、表示サイズが 10 以上でないと表示されないため、それより短い TIMESTAMP 値に対して HOUR() 操作を行っても、無意味な値しか得られない。

ある日付型の値を別の日付型のオブジェクトに割り当てることは、ある程度までは可能です。しかし、何らかの値の変化や情報の消失が起こる可能性があります。

• DATE 型の値を DATETIME または TIMESTAMP 型のオブジェクトに割り当てた場合、値に時刻情報が含まれていないため、結果の値の時刻部分は '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' として解釈される。値 '10:45:15' は、'45' が正しい月ではないため、'0000-00-00' に変換される。

• MySQL サーバでは、日 00-31、月 00-12、年 1000-9999 の有効性に関する基本チェックのみ実行される。この範囲外の日付はすべて 0000-00-00 に戻される。 この場合、2002-04-31 のような誤った日付も格納可能であることに注意する。Web アプリケーションでは、追加のチェックを行わずに、フォームからデータを格納できる。日付が有効なものかどうか確認するには、アプリケーションでチェックを行う必要がある。

• 2 桁で指定された年の値は、何世紀かわからないため、あいまいである。MySQL では、次の規則に基づいて、2 桁の年の値が解釈される。
  • 範囲 00-69 の年の値は 2000-2069 に変換

  • 範囲 70-99 の年の値は 1970-1999 に変換

6.2.2.3 TIME 型

MySQL では、TIME 型の値の取り出しと表示は、'HH:MM:SS' 形式（時間の部分が大きい値では 'HHH:MM:SS' 形式）で行われます。TIME 値の範囲は '-838:59:59' 〜 '838:59:59' です。時間の部分が大きい理由は、TIME 型が 1 日の時刻を表現するためだけでなく、経過時間や 2 つのイベント間の間隔を表現するために使用される場合があるためです。1 日の時刻は 24 時以上になることはありませんが、イベント間の経過時間は 24 時間を大きく上回ったり、マイナスになったりすることがあります。

TIME 型の値は、次に示すさまざまな形式で指定することができます。

• 'D HH:MM:SS.fraction' 形式の文字列として指定（注意: MySQL では、小数部は今のところ時刻カラムに格納されない）。"柔軟" な構文として、HH:MM:SS.fraction、HH:MM:SS、HH:MM、D HH:MM:SS、D HH:MM、D HH、SS のいずれかも使用できる。この場合、D は 0 〜 33 の間の日。

• 区切り記号のない、'HHMMSS' 形式の文字列（時刻として適切なもの）として指定。たとえば、'101112' は '10:11:12' として認識されるが、'109712' は正しくないため（分部分が不適切）、'00:00:00' になる。

• HHMMSS 形式の数値（時刻として適切なもの）として指定。 たとえば、101112 は '10:11:12' として認識される。代替形式として、SS、MMSS、HHMMSS、HHMMSS.fraction も認識される。MySQL では、小数部分は今のところ格納されないことに注意する。

• TIME 型のコンテキストで許容される値を返す、CURRENT_TIME などの関数の結果として指定。

TIME 型の値を時刻部分の区切り記号を含む文字列として指定する場合、10 より少ない時、分、または秒の値を 2 桁で指定する必要はありません。'8:3:2' は '08:03:02' と同じです。

TIME 型のカラムに "短い" TIME 値を割り当てるときは注意してください。MySQL では、コロンがない場合、右側の桁が秒を表すという前提にたって値を解釈します（この場合、TIME 型の値は 1 日の時刻ではなく、経過時間として解釈されます）。たとえば、'1112' や 1112 は、'11:12:00'（11 時 12 分）を表すように見えますが、MySQL では、'00:11:12'（11 分 12 秒）として解釈されます。 同様に、'12' や 12 は '00:00:12' として解釈されます。 それに対し、コロンのある TIME 値は、常に 1 日の時刻として扱われます。そのため、'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' 値から見分けることはできないことに注意してください。

6.2.2.4 YEAR 型

YEAR 型は、年を表現するときに使用する 1 バイトの型です。

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 桁の数値の範囲は、2 桁の文字列の範囲と多少異なる。数値として指定した場合、ゼロを直接入力して 2000 と解釈させることはできない。2000 と解釈させるには、必ず文字列の '0' または '00' として指定する必要がある。数値として指定すると、0000 として解釈される。

• YEAR 型のコンテキストで許容される値を返す、NOW() などの関数の結果として指定。

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

6.2.3 文字列型

6.2.3.1 CHAR 型と VARCHAR 型
6.2.3.2 BLOB 型と TEXT 型
6.2.3.3 ENUM 型
6.2.3.4 SET 型

文字列型には、CHAR、VARCHAR、BLOB、TEXT、ENUM、SET があります。このセクションでは、これらの型の機能を示すとともに、それぞれの記憶容量と、クエリでの使用方法について説明します。

6.2.3.1 CHAR 型と VARCHAR 型

CHAR 型と VARCHAR 型は似ていますが、格納および取り出しの方法が異なります。

CHAR 型のカラムの長さは、テーブルの作成時に宣言した長さに固定されます。この長さとして、1 〜 255 の任意の値を指定することができます（MySQL バージョン 3.23 以降では、CHAR 型の長さとして、0 〜 255 が可能)。CHAR 型の値は、格納時に、指定された長さになるよう右側にスペースが埋め込まれます。CHAR 値の取り出し時には、後続のスペースが削除されます。

VARCHAR 型のカラムの値は可変長の文字列です。VARCHAR カラムは、CHAR カラム同様、1 〜 255 の間の任意の長さとして宣言することができます。しかし、CHAR 型の値とは異なり、VARCHAR 型の値は、必要な文字と、長さを記録するための 1 バイトのみで格納されます。値に埋め込み処理が行われることはありません。値の格納時、後続のスペースは削除されます（このスペースの削除は SQL-99 の仕様と異なります）。格納時や取り出し時に、ケースの変換処理は行われません。

CHAR 型または VARCHAR 型のカラムに、そのカラムの最大長を超える値を割り当てると、カラムのサイズに合わせて値が切り捨てられます。

次の表に、さまざまな文字列値を CHAR(4) 型と VARCHAR(4) 型のカラムを格納したときの結果に基づく、これらのカラム型の違いについて示します。

CHAR 型のカラムでは、値の取り出し時に後続のスペースが削除されるため、CHAR(4) 型と VARCHAR(4) 型から取り出した値はそれぞれの場合で変わりません。

CHAR 型と VARCHAR 型のカラム値のソートと比較は、テーブルの作成時に BINARY 属性が指定されている場合を除いて、ケース非依存方式で行われます。BINARY 属性は、カラム値のソートと比較を、MySQL サーバが稼動しているマシンの ASCII 順に従って、ケース依存方式で行うことを表します。BINARY 属性はカラムの格納方法と取り出し方法には影響しません。

バージョン 4.1.0 以降では、カラム型 CHAR BYTE が CHAR BINARY として使用されます。これは互換性を考慮した機能です。

BINARY 属性は強固な属性です。BINARY として設定したカラ