Go to the first, previous, next, last section, table of contents.

6 MySQL Language Reference

MySQL has a very complex, but intuitive and easy to learn SQL interface. This chapter describes the various commands, types, and functions you will need to know in order to use MySQL efficiently and effectively. This chapter also serves as a reference to all functionality included in MySQL. In order to use this chapter effectively, you may find it useful to refer to the various indexes.

6.1 Language Structure

6.1.1 文字列と数値をどのように書くか？

この節は MySQL で文字列と数値を記述するさまざまな方法を説明します。 MySQL でのこれらの基本型の取り扱い時に、出会うであろうさまざまなニュアンスと ``了解'' もカバーします。

6.1.1.1 文字列

文字列は文字の並びです。引用符(`'')または二重引用符(`"')で括られます(後者は ANSI モードで実行していない場合のみ)。例：

'a string'
"another string"

文字列中では、いくつかのシーケンスは特別な意味を持ちます。これらのシーケンスのそれぞれはエスケープ文字として知られるバックスラッシュ (`\')で始まります。MySQL は次のエスケープシーケンスを認識します。

\0: ASCII 0 (NUL) 文字。
\': 引用符(`'')。
\": 二重引用符(`"')。
\b: バックスペース文字。
\n: 改行文字。
\r: リターン文字。
\t: タブ文字。
\z: ASCII(26) (Control-Z)。この文字は、ASCII(26) が Windows では END-OF-FILE であるという問題を回避するために、コード化できます。(ASCII(26) は mysql database < filename を使用しようとする場合に問題になります)。
\\: バックスラッシュ(`\')文字。
\%: `%' 文字。これは `%' がワイルドカード文字として解釈される文脈で、`%' そのものを検索するために使用されます。「6.3.2.1 String Comparison Functions」節参照.
\_: _ 文字。これは `_' がワイルドカード文字として解釈される文脈で、_ そのものを検索するために使用されます。「6.3.2.1 String Comparison Functions」節参照.

いくつかの文字列文脈で `\%' または `\_' を使用すると、これらは文字列 `%' と `_' ではなく、`\%' と `\_' を返します。

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

`'' で括られる文字列中の `'' は `''' として書くことができます。
`"' で括られる文字列中の `"' は `""' として書くことができます。
引用符の前にエスケープ文字 (`\') を置くことができます。
`"' で括られた文字列中の `'' は特別扱いの必要はなく、二重にしたり、エスケープする必要はありません。同じように、`'' で括られた文字列中の `"' は特別扱いの必要はありません。

次の 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() を使用できます。「8.4.2 C API 関数概要」節参照. Perl では、DBI パッケージの quote メソッドを使用して、特殊文字を適当なエスケープシーケンスに変換できます。「8.2.2 The DBI Interface」節参照.

上記の特殊文字のどれかを含む可能性のある全ての文字列について、エスケープ関数を使用すべきです！

Alternatively, many MySQL APIs provide some sort of placeholder capability that allows you to insert special markers into a query string, and then bind data values to them when you issue the query. In this case, the API takes case of escaping special characters in the values for you automatically.

6.1.1.2 数値

整数は数字の並びで表現されます。浮動小数点は `.' で小数を分割します。どちらの型も負数を表すために `-' を前につけます。

正当な数値の例:

1221
0
-32

有効な浮動小数点の例：

294.42
-32032.6809e+10
148.00

整数が浮動小数点の文脈で使用されるかもしれません；この場合、浮動小数点に変換されます。

6.1.1.3 16進法の値

MySQL は16進法の値をサポートします。数値の文脈では、これらは整数(64ビット精度)のように振る舞います。文字列の文脈では、hexの桁のそれぞれのペアが文字に変換されたバイナリー文字のように振る舞います。

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

The x'hexstring' syntax (new in 4.0) is based on ANSI SQL and the 0x syntax is based on ODBC. 16進数表記は、ODBC において BLOB の値を与えるためにしばしば使用されます。 You can convert a string or a number to hexadecimal with the HEX() function.

6.1.1.4 `NULL` 値

NULL は ``no data'' を意味し、数値型の 0 や文字列型の空文字列とは異なることに注意してください。「A.5.3 NULL 値での問題」節参照.

テキストファイルの読み込みや書き出し時に、NULL は \N で表現されます。 (LOAD DATA INFILE, SELECT ... INTO OUTFILE). 「6.4.9 LOAD DATA INFILE 構文」節参照.

6.1.2 データベース名、テーブル名、インデックス名、フィールド名、エイリアス名

データベース名、テーブル名、インデックス名、フィールド名、エイリアス名は MySQL では全て同じ規則に基づきます:

注意: 規則は MySQL 3.23.6 で変更されました。それは識別子(データベース名、テーブル名、フィールド名)の ``' でのクォートを導入した時です (ANSI モードで実行する場合は、" も識別子をクォートするために働きます)。

識別子	最大長	許される文字
データベース	64	ディレクトリ名として許されるすべての文字。`/`, `\', `.' を除く。
テーブル	64	ファイル名として許されるすべての文字。`/` と `.` を除く。
フィールド	64	すべての文字
エイリアス	255	すべての文字

注意: 上記に加え、識別子内には ASCII(0) と ASCII(255) を持てません。

注意: 識別子が制限された単語であったり特殊文字を含む場合は、それを使用する時には常に ` (バッククォート) でクォートする必要があります:

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

「6.1.7 Is MySQL Picky About Reserved Words?」節参照.

MySQL 3.23.6 より前のバージョンでは、名前の規則は次に従います:

名前は、現在の文字セットのアルファベットと数字文字から成り、`_' と `$' も含みます。デフォルト文字セットは ISO-8859-1 Latin1 ですが、これは mysqld に --default-character-set オプションを与えることで変更できます. (3.23.14 以上の場合のみ。それ以前のバージョンでは MySQL 再コンパイルが必要) 「4.6.1 データとソートに使用されるキャラクター・セット」節参照.
名前は、名前として正しい任意の文字で始めることができます。特に、名前は数字で始めることができます(これは他の多くのシステムと異なります！)。しかし、数字だけの名前にする事はできません。
名前の中に `.' 文字を使用することはできません。フィールドを参照できるように形式を拡張するために使用されるためです(後述)。

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

MySQL では次の形式のいずれかを使用してフィールドを参照できます:

フィールドの参照方法	意味
`col_name`	クエリ中で使用されるテーブル内に存在している `col_name` という名前のフィールド
`tbl_name.col_name`	現在のデータベースのテーブル `tbl_name` 内のフィールド `col_name`
`db_name.tbl_name.col_name`	データベース `db_name` のテーブル `tbl_name` 内のフィールド `col_name`。この形式はバージョン 3.22 以降で有効です。
`column_name`	キーワードであったり特殊文字を含むフィールド。

参照が曖昧でないならば、ステートメント中のフィールド参照の前に tbl_name または db_name.tbl_name を記述する必要はありません。例えば、テーブル t1 と t2 がそれぞれフィールド c を含み、t1 と t2 の両方を使用する SELECT ステートメントで c を取り出すとします。この場合、c はステートメントで使用されるテーブル間で唯一でないので曖昧です。そのため、t1.c または t2.c と記述するこよによりどちらのテーブルを意味するかを示す必要があります。同様に、データベース db1 のテーブル t とデータベース db2 のテーブル t から取り出す場合、これらのテーブル中の項目は、db1.t.col_name と db2.t.col_name として参照する必要があります。

構文 .tbl_name は現在のデータベース内のテーブル tbl_name を意味します。この構文はいくつかの ODBC が `.' 文字をテーブル名の前に置くために許されています。

6.1.3 名前のケース依存性

MySQL では、データベースとテーブルは、ディレクトリとそのディレクトリ中のファイルに対応します。そのため、下で動作するオペレーティングシステムのケース依存性は、データベースとテーブル名のケース依存性を決定します。データベース名とテーブル名は UNIX ではケース依存で、Windows ではケース非依存です。One prominent exception here is Mac OS X, when the default HFS+ file system is being used. However Mac OS X also supports UFS volumes, those are case sensitive on Mac OS X just like they are on any Unix. 「1.7.3 MySQL の ANSI SQL92 に対する拡張」節参照.

注意: 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;

テーブル名に使用されたケースを覚えておくことに問題があるなら、常にデータベースとテーブルに小文字の名前をつけるというような、一貫した慣習を採用してください。

この問題を回避する一つの方法は、mysqld を -O lower_case_table_names=1 をつけて起動することです。デフォルトではこのオプションは Windows では 1 で UNIX では 0 です。

lower_case_table_names が 1 の場合、MySQL はディスク上のすべてのテーブル名を小文字に変換して検索します。 (From version 4.0.2, this option also applies to database names.) 注意: このオプションを変更した場合、mysqld を起動する前に、最初に古いテーブル名を小文字に変換することが必要です。

If you move MyISAM files from a Windows to a Unix disk, you may in some cases need to use the `mysql_fix_extensions' tool to fix-up the case of the file extensions in each specified database directory (lowercase `.frm', uppercase `.MYI' and `.MYD'). `mysql_fix_extensions' can be found in the `scripts' subdirectory.

6.1.4 ユーザー変数

MySQL は、@variablename 構文で接続固有の変数をサポートします。変数名は現在の文字セットのアルファベットと数字、それに `_'、`$'、`.' 文字からなります。デフォルト文字セットは ISO-8859-1 Latin1 です。これは mysqld に --default-character-set オプションを与えることで変更できます. (3.23.14 以上の場合のみ。それ以前のバージョンでは MySQL 再コンパイルが必要) 「4.6.1 データとソートに使用されるキャラクター・セット」節参照.

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

SET 構文で変数を設定できます:

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

SET 構文で、式中で変数を設定することも可能です。 However, in this case the assignment operator is := rather than =, because = is reserved for comparisons in non-SET statements:

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 ステートメントでは、それぞれの式はクライアントに送られた時にだけ評価されます。これは、SELECT 部で設定された変数を必要とする式を参照する HAVING, GROUP BY, ORDER BY 節ができないことを意味します。例えば、次のステートメントは期待通りには動作しません:

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

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

The rule is to never assign and use the same variable in the same statement.

6.1.5 System Variables

Starting from MySQL 4.0.3 we provide better access to a lot of system and connection variables. One can change most of them without having to take down the server.

There are two kind of system variables: Thread-specific (or connection-specific) variables that are unique to the current connection and global variables that are used to configure global events. Global variables also are used to set up the initial values of the corresponding thread-specific variables for new connections.

When mysqld starts, all global variables are initialised from command line arguments and option files. You can change the value with the SET GLOBAL command. When a new thread is created, the thread-specific variables are initialised from the global variables and they will not change even if you issue a new SET GLOBAL command.

To set the value for a GLOBAL variable, you should use one of the following syntaxes: (Here we use sort_buffer_size as an example variable)

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

To set the value for a SESSION variable, you can use one of the following syntaxes:

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

If you don't specify GLOBAL or SESSION then SESSION is used. 「5.5.6 SET 構文」節参照.

LOCAL is a synonym for SESSION.

To retrieve the value for a GLOBAL variable you can use one of the following commands:

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

To retrieve the value for a SESSION variable you can use one of the following commands:

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

When you retrieve a variable value with the @@variable_name syntax and you don't specify GLOBAL or SESSION then MySQL will return the thread-specific (SESSION) value if it exists. If not, MySQL will return the global value.

The reason for requiring GLOBAL for setting GLOBAL only variables but not for retrieving them is to ensure that we don't later run into problems if we later would introduce a thread-specific variable with the same name or remove a thread-specific variable. In this case, you could accidentally change the state for the server as a whole, rather than just for your own connection.

The following is a full list of all variables that you change and retrieve and if you can use GLOBAL or SESSION with them.

Variable name	Value type	Type
autocommit	bool	SESSION
big_tables	bool	SESSION
binlog_cache_size	num	GLOBAL
bulk_insert_buffer_size	num	GLOBAL \| SESSION
concurrent_insert	bool	GLOBAL
connect_timeout	num	GLOBAL
convert_character_set	string	SESSION
delay_key_write	OFF \| ON \| ALL	GLOBAL
delayed_insert_limit	num	GLOBAL
delayed_insert_timeout	num	GLOBAL
delayed_queue_size	num	GLOBAL
error_count	num	LOCAL
flush	bool	GLOBAL
flush_time	num	GLOBAL
foreign_key_checks	bool	SESSION
identity	num	SESSION
insert_id	bool	SESSION
interactive_timeout	num	GLOBAL \| SESSION
join_buffer_size	num	GLOBAL \| SESSION
key_buffer_size	num	GLOBAL
last_insert_id	bool	SESSION
local_infile	bool	GLOBAL
log_warnings	bool	GLOBAL
long_query_time	num	GLOBAL \| SESSION
low_priority_updates	bool	GLOBAL \| SESSION
max_allowed_packet	num	GLOBAL \| SESSION
max_binlog_cache_size	num	GLOBAL
max_binlog_size	num	GLOBAL
max_connect_errors	num	GLOBAL
max_connections	num	GLOBAL
max_error_count	num	GLOBAL \| SESSION
max_delayed_threads	num	GLOBAL
max_heap_table_size	num	GLOBAL \| SESSION
max_join_size	num	GLOBAL \| SESSION
max_sort_length	num	GLOBAL \| SESSION
max_tmp_tables	num	GLOBAL
max_user_connections	num	GLOBAL
max_write_lock_count	num	GLOBAL
myisam_max_extra_sort_file_size	num	GLOBAL \| SESSION
myisam_max_sort_file_size	num	GLOBAL \| SESSION
myisam_sort_buffer_size	num	GLOBAL \| SESSION
net_buffer_length	num	GLOBAL \| SESSION
net_read_timeout	num	GLOBAL \| SESSION
net_retry_count	num	GLOBAL \| SESSION
net_write_timeout	num	GLOBAL \| SESSION
query_cache_limit	num	GLOBAL
query_cache_size	num	GLOBAL
query_cache_type	enum	GLOBAL
read_buffer_size	num	GLOBAL \| SESSION
read_rnd_buffer_size	num	GLOBAL \| SESSION
rpl_recovery_rank	num	GLOBAL
safe_show_database	bool	GLOBAL
server_id	num	GLOBAL
slave_compressed_protocol	bool	GLOBAL
slave_net_timeout	num	GLOBAL
slow_launch_time	num	GLOBAL
sort_buffer_size	num	GLOBAL \| SESSION
sql_auto_is_null	bool	SESSION
sql_big_selects	bool	SESSION
sql_big_tables	bool	SESSION
sql_buffer_result	bool	SESSION
sql_log_binlog	bool	SESSION
sql_log_off	bool	SESSION
sql_log_update	bool	SESSION
sql_low_priority_updates	bool	GLOBAL \| SESSION
sql_max_join_size	num	GLOBAL \| SESSION
sql_quote_show_create	bool	SESSION
sql_safe_updates	bool	SESSION
sql_select_limit	bool	SESSION
sql_slave_skip_counter	num	GLOBAL
sql_warnings	bool	SESSION
table_cache	num	GLOBAL
table_type	enum	GLOBAL \| SESSION
thread_cache_size	num	GLOBAL
timestamp	bool	SESSION
tmp_table_size	enum	GLOBAL \| SESSION
tx_isolation	enum	GLOBAL \| SESSION
version	string	GLOBAL
wait_timeout	num	GLOBAL \| SESSION
warning_count	num	LOCAL
unique_checks	bool	SESSION

Variables that are marked with num can be given a numerical value. Variables that are marked with bool can be set to 0, 1, ON or OFF. Variables that are of type enum should normally be set to one of the available values for the variable, but can also be set to the number that correspond to the enum value. (The first enum value is 0).

Here is a description of some of the variables:

Variable	Description
identity	Alias for last_insert_id (Sybase compatiblity)
sql_low_priority_updates	Alias for low_priority_updates
sql_max_join_size	Alias for max_join_size
delay_key_write_for_all_tables	If this and delay_key_write are set, then all new MyISAM tables that are opened will use delayed key writes.
version	Alias for VERSION() (Sybase (?) compatability)

A description of the other variable definitions can be found in the startup options section, the description of SHOW VARIABLES and in the SET section. 「4.1.1 mysqld コマンド行オプション」節参照. 「4.5.6.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;

-- コメントスタイルは -- の後ろに最低一つのスペースが必要であることに注意！

サーバーはコメント構文を理解しますが、 mysql クライアントが /* ... */ コメントを分析するにはいくつか制限があります：

シングルクウォートとダブルクオート文字は引用文字列のトークンの開始を示します。たとえコメントの中であっても。もしコメントの中でクオートが二つ目のクオートにマッチしなかった場合、パーサーはコメントが終了していないと認識します。 mysql を対話モードで実行している場合、プロンプトが mysql> から '> か "> に変わります。
セミコロンは SQL 構文の終了を示し、これに続く文字は次の構文の開始となります。

これらの制限は mysql を対話モードで実行している場合と、 mysql にファイルを読み込ませている場合 ( mysql < some-file ) の両方で現れます。

MySQL は ANSI SQL コメントの `--' をサポートしません。「1.7.4.7 コメント開始としての `--'」節参照.

6.1.7 Is MySQL Picky About Reserved Words?

共通の問題は、フィールドの名前を、 TIMESTAMP とか GROUP とかの MySQL に埋め込まれているデータ型や関数名と同名にして、テーブルを作った場合に起こります。このようなことは行えます(例えば ABS はフィールド名にできます)。しかし、関数として使用する場合、この名前がフィールド名として使用されているなら、関数名と `(' の間の空白は許されません。

以下の語は MySQL に予約されています。これらのほとんどは、 ANSI SQL92 によって、テーブル、フィールド名としての使用は禁止されています。(例えば GROUP)。またいくつかの語は MySQL が必要とし、 yacc パーサーで使用しているので予約されています。

Word	Word	Word
`ADD`	`ALL`	`ALTER`
`ANALYZE`	`AND`	`AS`
`ASC`	`AUTO_INCREMENT`	`BDB`
`BEFORE`	`BERKELEYDB`	`BETWEEN`
`BIGINT`	`BINARY`	`BLOB`
`BOTH`	`BTREE`	`BY`
`CASCADE`	`CASE`	`CHANGE`
`CHAR`	`CHARACTER`	`CHECK`
`COLLATE`	`COLUMN`	`COLUMNS`
`CONSTRAINT`	`CREATE`	`CROSS`
`CURRENT_DATE`	`CURRENT_TIME`	`CURRENT_TIMESTAMP`
`DATABASE`	`DATABASES`	`DAY_HOUR`
`DAY_MINUTE`	`DAY_SECOND`	`DEC`
`DECIMAL`	`DEFAULT`	`DELAYED`
`DELETE`	`DESC`	`DESCRIBE`
`DISTINCT`	`DISTINCTROW`	`DIV`
`DOUBLE`	`DROP`	`ELSE`
`ENCLOSED`	`ERRORS`	`ESCAPED`
`EXISTS`	`EXPLAIN`	`FALSE`
`FIELDS`	`FLOAT`	`FOR`
`FORCE`	`FOREIGN`	`FROM`
`FULLTEXT`	`FUNCTION`	`GRANT`
`GROUP`	`HASH`	`HAVING`
`HIGH_PRIORITY`	`HOUR_MINUTE`	`HOUR_SECOND`
`IF`	`IGNORE`	`IN`
`INDEX`	`INFILE`	`INNER`
`INNODB`	`INSERT`	`INT`
`INTEGER`	`INTERVAL`	`INTO`
`IS`	`JOIN`	`KEY`
`KEYS`	`KILL`	`LEADING`
`LEFT`	`LIKE`	`LIMIT`
`LINES`	`LOAD`	`LOCALTIME`
`LOCALTIMESTAMP`	`LOCK`	`LONG`
`LONGBLOB`	`LONGTEXT`	`LOW_PRIORITY`
`MASTER_SERVER_ID`	`MATCH`	`MEDIUMBLOB`
`MEDIUMINT`	`MEDIUMTEXT`	`MIDDLEINT`
`MINUTE_SECOND`	`MOD`	`MRG_MYISAM`
`NATURAL`	`NOT`	`NULL`
`NUMERIC`	`ON`	`OPTIMIZE`
`OPTION`	`OPTIONALLY`	`OR`
`ORDER`	`OUTER`	`OUTFILE`
`PRECISION`	`PRIMARY`	`PRIVILEGES`
`PROCEDURE`	`PURGE`	`READ`
`REAL`	`REFERENCES`	`REGEXP`
`RENAME`	`REPLACE`	`REQUIRE`
`RESTRICT`	`RETURNS`	`REVOKE`
`RIGHT`	`RLIKE`	`RTREE`
`SELECT`	`SET`	`SHOW`
`SMALLINT`	`SOME`	`SONAME`
`SPATIAL`	`SQL_BIG_RESULT`	`SQL_CALC_FOUND_ROWS`
`SQL_SMALL_RESULT`	`SSL`	`STARTING`
`STRAIGHT_JOIN`	`STRIPED`	`TABLE`
`TABLES`	`TERMINATED`	`THEN`
`TINYBLOB`	`TINYINT`	`TINYTEXT`
`TO`	`TRAILING`	`TRUE`
`TYPES`	`UNION`	`UNIQUE`
`UNLOCK`	`UNSIGNED`	`UPDATE`
`USAGE`	`USE`	`USER_RESOURCES`
`USING`	`VALUES`	`VARBINARY`
`VARCHAR`	`VARCHARACTER`	`VARYING`
`WARNINGS`	`WHEN`	`WHERE`
`WITH`	`WRITE`	`XOR`
`YEAR_MONTH`	`ZEROFILL`

The following symbols (from the table above) are disallowed by ANSI SQL but allowed by MySQL as column/table names. This is because some of these names are very natural names and a lot of people have already used them.

ACTION
BIT
DATE
ENUM
NO
TEXT
TIME
TIMESTAMP

6.2 フィールド型

MySQLは多くのフィールド型をサポートしており、それらは３つのカテゴリにグループ化されます: 数値型、日付及び時間型、そして文字列(文字)型。この章ではまず、利用できる型の概要から始まり、それから各カテゴリの各フィールド型の所要記憶容量の要約と、型の属性についてのより詳細な情報を提供します。概要は意図的に簡潔にまとめています。値として指定できる書式のようなフィールド型固有の付加情報は、詳細の説明部にて調べて下さい。

MySQLでサポートされるフィールド型は以下に示す通りです。後に続く文字の意味は説明のために使われます:

M: 最大表示サイズを意味します。最大の表示桁数は 255.
D: 浮動小数点数型に適用され、小数点以下の桁数を表します。最大の値は 30 ですが、これは M-2 より大きくなってはいけません。

中カッコ(`['及び`]')は型定義の一部であり、それがオプションであることを表します。

もしあるフィールドに ZEROFILL を指定した場合、 MySQL は自動で UNSIGNED 属性をそのフィールドに追加します。

Warning: you should be aware that when you use subtraction between integer values where one is of type UNSIGNED, the result will be unsigned! 「6.3.5 Cast Functions」節参照.

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

とても小さい整数。符号つきの範囲は -128～127。符号なしの範囲は 0～255。

BIT

BOOL

These are synonyms for TINYINT(1).

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 bits) よりも大きな整数をビット関数以外で使用すべきではありません！それを行なうと、結果の最後の桁のいくつかは不正になるでしょう BIGINT を DOUBLE に変換する時の丸めエラーのためです。 MySQL 4.0 can handle BIGINT in the following cases:
- Use integers to store big unsigned values in a BIGINT column.
- In MIN(big_int_column) and MAX(big_int_column).
- When using operators (+, -, *, etc.) where both operands are integers.
文字列として格納することで BIGINT フィールドの正確な整数値を常に格納することができます。この場合、double 表現を介在しません。
-、+及び*は、両方の引数がINTEGER値の時、 BIGINT演算を使うことに注意して下さい！これは、２つの大きな整数のかけ算を行なう(又は整数を返す関数の結果が大きな整数である)時、結果が9223372036854775807よりも大きい場合に予期しない結果を受け取ることがあるということを意味しています。

FLOAT(precision) [UNSIGNED] [ZEROFILL]

浮動小数点数。Version 4.0 未満では符号なしにはできません。単精度浮動小数点数では precision が <=24 で、倍精度浮動小数点数では 25～53 の間です。これらの型は次で述べるFLOATやDOUBLE型に似ています。 FLOAT(X)は、FLOAT及びDOUBLE型に一致する同じ範囲を持っていますが、表示サイズや小数点以下桁数が定義されません。 MySQL バージョン 3.23 では、これは正しい浮動小数点です。前の MySQL バージョンでは, FLOAT(precision) は常に小数部は2桁でした。注意: FLOAT の使用は、MySQL での全ての演算が double 精度で行なわれるため、いくつかの予期しない問題が起こり得ます。「A.5.6 Solving Problems with No Matching Rows」節参照. この構文は ODBC 互換です。

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

小さい浮動小数点数。Version 4.0 未満では符号なしにはできません。範囲は -3.402823466E+38～-1.175494351E-38、 0、 1.175494351E-38～3.402823466E+38です。 Version 4.0 以上では、If UNSIGNED is specified, negative values are disallowed. M は表示幅で D は小数部桁数です。引数が無いか引数が24以下の FLOAT は単精度浮動小数点数を意味します。

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

通常の浮動小数点数。Version 4.0 未満では符号なしにはできません。範囲は -1.7976931348623157E+308～-2.2250738585072014E-308 、 0、2.2250738585072014E-308～1.7976931348623157E+308です。 Version 4.0 以上では、If UNSIGNED is specified, negative values are disallowed. M は表示幅で D は小数部桁数です。引数が無いか DOUBLE か、 25 <= X <= 53 である FLOAT(X) は倍精度浮動小数点数を意味します。

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

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

これらはDOUBLEの同義語です。

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

パック無し浮動小数点数。Version 4.0 未満では符号なしにはできません。CHARフィールドのように振舞います。`パック無し'は、数値が文字列として格納されることを意味し、数値のそれぞれの桁、小数点、及び負数での`-'符号に１文字使用します。 Dが0の時、値は小数点や小数部を持ちません。DECIMAL値の最大範囲は DOUBLEと同じですが、実際の範囲はDECIMALフィールドに与えられたM 及びDの選択に強制されます。 Version 4.0 以上では、If UNSIGNED is specified, negative values are disallowed. D を省略した場合は 0 に設定されます。M を省略した場合は 10 に設定されます。 MySQL 3.22 以下では、 M 引数は符号や小数点を含みます。

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

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

DECIMALと同じ。

DATE

日付。サポートされる範囲は'1000-01-01'から'9999-12-31'まで。 MySQL は'YYYY-MM-DD'の書式でDATE値を表示しますが、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 はTIMESTAMP値をYYYYMMDDHHMMSS、YYMMDDHHMMSS、 YYYYMMDD又はYYMMDDという書式で表示し、それはMに14(もしくは誤ってそれ以上の値を指定した時)、12、8又は6のいずれが指定されたかに依存します。しかしながらTIMESTAMPフィールドへの値の割当ては、文字列もしくは数値のいずれかの使用が許されます。 TIMESTAMPフィールドは、最後に操作された時刻を自動的に設定するので、 INSERTやUPDATE操作の時刻を記録するのに役立ちます。 NULL値を与えることによっても、現在時刻を設定できます。「6.2.2 日付と時間の型」節参照. TIMESTAMP は常に 4 バイトで格納されます。M 引数は TIMESTAMP フィールドがどのように表示されるかだけに影響します。注意: X が 8 または 14 である TIMESTAMP(X) フィールドは数値として報告されます。他の TIMESTAMP(X) フィールドは文字列として報告されます。これは、これらの型を持ったテーブルを確実にダンプとリストアできるようにするためです！「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桁形式(70～69)では 1970～2069 です。MySQL は YEAR 値を YYYY 形式で表示しますが、 YEAR フィールドへの値の割り当ては文字列と数字のどちらでも使用できます。(YEAR は MySQL バージョン 3.22 以上での新しい型です。) 「6.2.2.4 YEAR 型」節参照.

[NATIONAL] CHAR(M) [BINARY]

固定長文字列で、格納時には必ず指定された長さまで右側に空白を埋めます。 Mの範囲は 0 から 255 文字です。 (MySQL Version 3.23 までは 1 から 255 です。) 後続の空白は値の取り出し時に削除されます。BINARY キーワードが与えられない場合、CHAR 値のソートと比較は、デフォルト文字セットに従ってケース非依存の方法で行なわれます。 NATIONAL CHAR (短い形式は NCHAR) は、ANSI SQL で、CHAR フィールドがデフォルト文字セットを使用することを定義する方法です。これは MySQL ではデフォルトです。 CHAR は CHARACTER の略記です。 MySQL は CHAR(0) 型のフィールドの生成を許します。これは主に、実際にはもう値が使われていないフィールドが存在することに依存しているようないくつかの古いアプリケーションに対応する必要がある時に便利です。２つの値だけを取ることができるフィールドを必要とする時にもとても良いことです: NOT NULL として定義されていない CHAR(0) は1ビットだけを占有し、２つの値だけを取ることができます: NULL または ""。「6.2.3.1 CHAR 型と VARCHAR 型」節参照.

CHAR

This is a synonym for CHAR(1).

[NATIONAL] VARCHAR(M) [BINARY]

可変長文字列。注意: 後続の空白は格納時に削除されます(これは ANSI SQL 仕様と異なります)。 Mの範囲は 0 から 255 文字です。 (MySQL Version 4.0.2 未満では 1 から 255 です) BINARY キーワードが与えられない場合、ソートと比較はケースに依存しません。「6.5.3.1 暗黙のフィールド定義変更」節参照. VARCHAR は CHARACTER VARYING の略記です。「6.2.3.1 CHAR 型と VARCHAR 型」節参照.

TINYBLOB

TINYTEXT

最大長 255 (2^8 - 1) 文字の TEXT/BLOB。「6.5.3.1 暗黙のフィールド定義変更」節参照. 「6.2.3.2 BLOB と TEXT 型」節参照.

BLOB

TEXT

最大長 65535 (2^16 - 1) 文字の TEXT/BLOB。「6.5.3.1 暗黙のフィールド定義変更」節参照. 「6.2.3.2 BLOB と TEXT 型」節参照.

MEDIUMBLOB

MEDIUMTEXT

最大長 16777215 (2^24 - 1) 文字の TEXT/BLOB。「6.5.3.1 暗黙のフィールド定義変更」節参照. 「6.2.3.2 BLOB と TEXT 型」節参照.

LONGBLOB

LONGTEXT

最大長 4294967295 (2^32 - 1) 文字の TEXT/BLOB。「6.5.3.1 暗黙のフィールド定義変更」節参照。注意: サーバ／クライアントプロトコルと MyISAM テーブルは、通信パケット単位 / テーブルレコードで、現在 16M の制限があるため、この型の範囲全体はまだ使用できません。「6.2.3.2 BLOB と TEXT 型」節参照。

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

列挙。対象となる文字列は、値を一つだけ持ち、値リスト'value1', 'value2',...(又は NULL)から選ばれます。ENUMは最大65535個の固有値を持つことができます。「6.2.3.3 ENUM 型」節参照.

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

組。対象となる文字列は0以上の値を持ち、それぞれ値リスト'value1', 'value2',... から選ばれなければなりません。 SETは、最大 64個の要素を持つことができます。「6.2.3.4 SET 型」節参照.

6.2.1 数値型

MySQL は ANSI/ISO SQL92 数値型をすべてサポートします。これらの型は正確な数値データ型(NUMERIC, DECIMAL, INTEGER, SMALLINT)、近似数値型(FLOAT, REAL, DOUBLE PRECISION)を含みます。キーワード INT は INTEGER の同義語で、 DECは DECIMAL の同義語です。

MySQL では NUMERIC と DECIMAL 型は、SQL92 標準で許されているように同じ型として実装されています。これらは正確な精度を維持することが重要な値(例えば金銭データ)に使用されます。これらの型の一つのフィールドを宣言する時、精度と大きさが指定できます(通常はそうします); 例えば:

    salary DECIMAL(5,2)

この例では、5 (precisoin) は値を格納する重要な数値の桁数を表します。そして 2 (scale) は小数点に続いて格納される桁数を表します。従って、この場合 salary フィールドに格納することができる値の範囲は、-99.99 から 99.99 です。 (MySQL can actually store numbers up to 999.99 in this column because it doesn't have to store the sign for positive numbers)

ANSI/ISO SQL92 では、構文 DECIMAL(p) は DECIMAL(p,0) と等しいです。同様に、構文 DECIMAL は DECIMAL(p,0) と等しいです。ここで p の値の決定は実装に許されてます。DECIMAL/NUMERIC データ型のこれらの異なる形式は、MySQL は現在サポートしていません。この型の主な利益は精度と大きさの両方を明示的に制御する機能から引き出されるので、これは通常深刻な問題ではありません。

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

DECIMAL と NUMERIC 値の最大範囲は DOUBLE と同じです。しかし DECIMAL や NUMERIC フィールドに与えられる実際の範囲はフィールドに与えられた precision と scale によって強制されます。このフィールドに、指定された scale で許されるよりも多い桁の小数部を持つ数値が割り当てられた場合、値はその scale に丸められます。 DECIMAL や NUMERIC フィールドに、指定された(またはデフォルトの) precision と scale で示された範囲を超えた大きさの値を割り当てた時、MySQL はその範囲の対応する最大値を表す値を格納します。

ANSI/ISO SQL92 標準に対する拡張として、上の表にリストしたように、 MySQL は整数型 TINYINT, MEDIUMINT, BIGINT もサポートします。MySQL によってサポートされる他の拡張として、オプションで、型の基本キーワードに続けて括弧内に指定する整数値の表示幅(例えば INT(4))があります。このオプションの幅指定は、フィールドに指定された幅よりも少ない幅の値の表示の左側を埋めるために使用されます。しかしフィールドに格納することができる値の範囲や、フィールドに指定された幅を超える幅の値について表示される桁数は制約されません。オプションの拡張属性 ZEROFILL を指定して使用された場合、デフォルトの埋められる空白は 0 で置き換えられます。例えば、INT(5) ZEROFILL として宣言されたフィールドでは、値 4 は 0004 として取り出されます。注意: 整数フィールド内に表示幅よりも大きい値を格納する場合、MySQL が複雑な join のために一時テーブルを生成する時に、問題を体験するでしょう。この場合 MySQL はデータがオリジナルのフィールド幅に合っていることを信用するためです。

すべての整数型はオプションの(非標準)属性 UNSIGNED を持つことができます。符合無しの値はフィールド内に正の数だけを許可したくて、フィールドに対して少し大きい数値の範囲が必要な時に使用できます。

As of MySQL 4.0.2, floating-point types also can be UNSIGNED. As with integer types, this attribute prevents negative values from being stored in the column. Unlike the integer types, the upper range of column values remains the same.

FLOAT 型は近似数データ型を表すために使用されます。ANSI/ISO SQL92 標準は、FLOAT キーワードに続く括弧中にオプションの精度(指数の範囲ではない)の指定を許しています。MySQL 実装はこのオプションの精度指定もサポートしています。キーワード FLOAT が精度の指定無しでフィールド型として使用された時は、MySQL は値を格納するために4バイトを使用します。FLOAT キーワードに続く括弧中に2つの数値を与える構文もサポートされます。このオプションでの、最初の数値は値に必要な容量をバイトで表します。 2番目の数値は、格納、表示される小数部の桁数を指定します(DECIMAL と NUMERIC と同様)。MySQL がフィールドに指定されたよりも大きい小数部の桁数を持つ数値をこのフィールドに格納する時、値の格納時に余計な桁を取り除くように値が丸められます。

REAL と DOUBLE PRECISION 型は精度指定を許しません。 ANSI/ISO SQL92 標準に対する拡張として、MySQL は DOUBLE を DOUBLE PRECISION 型の同義語として認識します。REAL の精度は DOUBLE PRECISION の指定よりも小さいことを要求する標準と異なり、 MySQL はどちらも8バイトの倍精度小数点の値として実装しています (非"ANSI モード"で実行した場合)。移植性を最大にするためには、近似数値データ値の格納を要求するコードは、精度や小数部桁数の指定無しの FLOAT か DOUBLE PRECISION を使用すべきです。

フィールドの型の値の許容範囲を超えた数値を代入しようとすると、MySQL はその値を許容範囲いっぱいに切り詰め、その結果を代わりに代入します。

例えば、 INT フィールドの範囲は -2147483648 から 2147483647 です。もし -9999999999 を INT フィールドに挿入しようとすると、値は範囲の最低値に修正され、 -2147483648 が代わりに代入されます。同様に、 9999999999 の場合、 2147483647 が代わりに代入されます。

そして、INT フィールドが符号無しの場合、フィールドの範囲の大きさは同じですが、限界値は 0 と4294967296 になります。もし -9999999999 と 9999999999 を代入しようとすると、値は 0 と 4294967296 として代入されます。

ALTER TABLE, LOAD DATA INFILE, UPDATE または multi-row INSERT 時、これらの変換は `警告' として得られます。

Type	Bytes	From	To
`TINYINT`	1	-128	127
`SMALLINT`	2	-32768	32767
`MEDIUMINT`	3	-8388608	8388607
`INT`	4	-2147483648	2147483647
`BIGINT`	8	-9223372036854775808	9223372036854775807

6.2.2 日付と時間の型

日付と時間の型は DATETIME, DATE, TIMESTAMP, TIME, YEAR です. これらはそれぞれ値に適正な範囲があり、 ``zero'' はあなたが間違った値を指定した場合に用いられます。注意: MySQL は確実に '厳密でない' 正しい日付の値、例えば 1999-11-31 を格納することができます。この理由は、日付をチェックする処理の責任はアプリケーションにあり、SQL サーバにはないと考えているからです。日付を'速く'チェックするために、MySQL は月が 0～12 の範囲であるかと日が 0～31 の範囲であるかだけをチェックします。上述の範囲は、MySQL が DATE または DATETIME フィールドに、日または月日が 0 である日付を格納できるために定義されています。これは、正確な日付を知らない誕生日を登録する必要があるアプリケーションに非常に有用です。この場合、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 を使用することにより、より簡潔に書くこともできます。
MyODBC 内で使用されている `ゼロ' の日付と時間は、 MyODBC 2.50.12 以上では自動的に NULL に変換されます。これは ODBC がこれらの値を扱えないからです。

6.2.2.1 西暦２０００年問題とデータ型

MySQL 自体は2000年問題に対して安全です( 「1.2.5 2000 年対応」節参照)が、 MySQL に提示される入力値に関してはそうではありません。2桁の年の入力は何世紀なのかわからないので全て曖昧です。このような値は MySQL が内部で年に4桁を使っていることから4桁の形式に変換されてしまいます。

MySQL は曖昧な日付を DATETIME, DATE, TIMESTAMP および YEAR 型に関して、以下のルールに従って解釈します。

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 タイプは INSERT や UPDATE 操作に自動的に現在の日付と時刻をマークする場合に提供される型です。もし複数の TIMESTAMP フィールドがある場合には最初の一つだけが自動的に更新されます。

最初の TIMESTAMP フィールドの自動更新は以下のいずれかの条件で起こります：

そのフィールドが明示的に INSERT または LOAD DATA INFILE 文で指定されていないとき。
そのフィールドが明示的に UPDATE 文で指定されず、かつ、他のフィールドの値が変わった場合。 (もともとフィールドに入っていた値と同じ値に更新しようとする UPDATE 文は TIMESTAMP フィールドを更新しないことに注意。なぜならあるフィールドを現在と同じ値に変えようとしても MySQL は効率のためにそれを無視するからです。)
明示的に TIMESTAMP フィールドを NULL にした場合。

最初以外の TIMESTAMP フィールドも現在の日付と時刻にすることができます。それらのフィールドをNULL または NOW() にすることです。

どの TIMESTAMP フィールドも明示的に望む値をセットすることで現在の日時でない値にすることができます。それは最初の TIMESTAMP フィールドについても同じです。この特性は例えば TIMESTAMP フィールドをあるレコードが生成された時の日時にし、その後その行が更新されても変化しないようにしたいというようなときに使えます。

MySQL にレコードが生成されたときにそのフィールドをセットさせる。これで現在日時に初期化される。
以降の他のフィールドに対する更新時に TIMESTAMP フィールドをそれ自体が今持っている値に明示的に更新する。

一方、この手法は DATATIME フィールドを行生成時に NOW() で初期化し、以降の更新時にそれをほうっておくのと同じように簡単であるとわかるでしょう。

TIMESTAMP の値は 1970 年の最初から 2037 年のどこかの時点までの範囲で有効で、 1秒の時間分解能を持ちます。値は数値として表示されます。

MySQL が TIMESTAMP 値を取り出したり表示するのに使うフォーマットは以下の表に示すようにその表示サイズに依存します。「目一杯の」 TIMESTAMP フォーマットは14桁ですが、 TIMESTAMP フィールドはより短い表示サイズで生成することもできます：

フィールド型	表示フォーマット
`TIMESTAMP(14)`	`YYYYMMDDHHMMSS`
`TIMESTAMP(12)`	`YYMMDDHHMMSS`
`TIMESTAMP(10)`	`YYMMDDHHMM`
`TIMESTAMP(8)`	`YYYYMMDD`
`TIMESTAMP(6)`	`YYMMDD`
`TIMESTAMP(4)`	`YYMM`
`TIMESTAMP(2)`	`YY`

全ての TIMESTAMP フィールドは表示サイズに関係なく同じ格納サイズを持ちます。もっとも一般的な表示サイズは 6 , 8 , 12 および 14 です。表示サイズはテーブル生成時に任意の値に指定できますが、 0 および 14 以上の値は強制的に 14 になります。1 から 13 までの奇数のサイズは強制的に一つ大きい偶数になります。

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' フォーマット。「緩やかな」文法が認められていて、句読記号は日付、時刻部分の区切りとして使えます。例えば '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 または YYMDD のフォーマットの数値で日付として意味のあるもの。例えば 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 桁の長さの時はそれぞれ YYYYMMDD および YYYYMMDDHHMMSS フォーマットで、最初の 4 桁で年が与えられるものと仮定されます。もしその数値が 6または12桁の長さの時は YYMMDD および YYMMDDHHMMSS フォーマットで最初の2桁で年が与えられるものと仮定されます。これら以外の長さの数値はあとに 0 が追加されてこれらのうちのもっとも近い長さのものと解釈されます。

区切りなしの文字列で与えられる値はそれ自身の長さを使って解釈されます。もし文字列が8または14文字ならば年は最初の4文字で与えられると仮定されます。そうでなければ最初の2文字で与えられると仮定されます。文字列は左から右に年、月、日、時、分、秒と文字列中に表現されている分だけ順に解釈されます。つまり6文字以下の文字列は使ってはいけないということです。例えば1999年3月を指定するつもりで '9903' を指定した場合、MySQL は「ゼロ」日付をテーブルに挿入します。これは年と月の部分は 99 と 03 ですが日の部分が欠けている(ゼロ)ために値が有効な日付でないために起こります。

TIMESTAMP フィールドは有効な値を、表示サイズに関係なく指定された値を最高精度の時間分解能で格納します。このことはいくつかの意味合いを持ちます。

年の値が二桁で指定された場合、世紀の部分がないので曖昧な値となります。 MySQL は二桁の年の値を以下に示す規則にそって変換します：

列の型がTIMESTAMP(4)であってもTIMESTAMP(2)であっても常に年月日を指定すること。そうでなければ値は無効で0が格納されます。
もし短い形式の TIMESTAMP を ALTER TABLE を使って拡張しようとした場合、拡張前には「隠れていた」情報が現れます。
同様に TIMESTAMP フィールドを縮めた場合も、値が表示された時により少ない情報しか現れないという点を除いて、情報は失われません。
TIMESTAMP 値は最高精度の時間分解能で格納されますが、内部的に格納された値を直接操作できる関数は UNIX_TIMESTAMP() のみです。他の関数はフォーマットされて取り出された値について操作します。つまり、 HOUR() や SECOND() などの関数は TIMESTAMP 値の対応する部分がフォーマットされた値で含まれないと使うことができません。例えば TIMESTAMP 列の HH の部分は表示サイズが少なくとも10以上ないと表示されないので、それより短い TIMESTAMP 値に HOUR() の操作を行っても無意味な値しか得られません。

ある日付型を他の日付型のオブジェクトに拡張して指定することができます。しかしそれは値の変化や情報の欠落を起こす可能性があります。

DATE の値を DATETIME か TIMESTAMP の物に与えた場合、時刻の部分は '00:00:00' になります。これは DATE 値が時刻の情報を持っていないからです。
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' に変換されます。
The MySQL server only performs basic checking on the validity of a date: days 00-31, months 00-12, years 1000-9999. Any date not within this range will revert to 0000-00-00. Please note that this still allows you to store invalid dates such as 2002-04-31. It allows web applications to store data from a form without further checking. To ensure a date is valid, perform a check in your application.
2桁で表される年は世紀の部分が不明なので曖昧です。 MySQL は以下のルールで2桁の年を解釈します。
- 00-69 の範囲にある年の値は 2000-2069 年とする。
- 70-99 の範囲にある年の値は 1970-1999 年とする。

6.2.2.3 `TIME` 型

MySQL は TIME の値を 'HH:MM:SS' (時の部分が大きい場合は 'HHH:MM:SS') というフォーマットで扱い、また表示します。 (時の部分が大きい場合は 'HHH:MM:SS')。 TIME 値の範囲は '-838:59:59' から '838:59:59' の範囲です。時の部分がこんなに大きいのは、TIME 型は一日すなわち24時間以内の時刻を表現するのに用いられるだけではなく経過時間や二つの事象の間隔 (どちらも２４時間を越えたり、負の数になる場合もあります)を表現することもあるからです。

TIME 値は様々なフォーマットで指定可能です：

文字列で 'D HH:MM:SS.fraction' というフォーマット。 (MySQLはまだこの fraction を time フィールドに保存できません)。以下の ``柔軟な'' 文法が使用できます： 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' と解釈されますが '1097 12' は無効で(分の部分が無意味) '00:00:00' になります。
数値で HHMMSS のフォーマットで時刻として有効なもの。例えば 101112 は '10:11:12' と解釈されます。次の別の形式も解釈できます: SS, MMSS,HHMMSS, HHMMSS.fraction。注意: MySQL はまだ fraction 部を保存できません。
例えば CURRENT_TIME のように TIME のコンテキストで受け付けられる値を返す関数の結果。

文字列で時刻の各部の区切りを含む TIME の値については、時、分、秒が 10 以下の場合、２桁の数字を指定する必要はありません。'8:3:2' は '08:03:02' と同じです。

「短い」 TIME 値を TIME フィールドとして指定する場合は要注意です。コロンなしでは、MySQL はその値のもっとも右端の桁は秒を表すと仮定して解釈します。 (MySQL は TIME の値を一日のうちの時刻としてより経過時間として解釈します)。例えば '11:12','1112', 1112 が '11:12:00' (11時12分)を表しているつもりでいても、 MySQL はこれらを '00:11:12' (11分12秒)として解釈します。同様に '12' および 12 は '00:00:12' と解釈します。

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桁の文字列の場合と若干異なっている点に注意してください。なぜなら0を数値として指定し、それを2000年として解釈させることができないからです。その場合は文字列で '0' または '00' を指定しなければなりません。そうでなければ数値0は無効なYEAR値を示す 0000 に変換されます。
例えば NOW() のように YEAR コンテキストで受け入れられる値を返す関数の結果。

無効な YEAR 値は 0000 に変換されます。

6.2.3 文字列型

文字列型はCHAR, VARCHAR, BLOB, TEXT, ENUM, SET です。このセクションは、それらの型がどのように動作するかと、要求されるサイズと、クエリ内での使用方法を説明します。

Type	Max.size	Bytes
`TINYTEXT` or `TINYBLOB`	2^8-1	255
`TEXT` or `BLOB`	2^16-1 (64K-1)	65535
`MEDIUMTEXT` or `MEDIUMBLOB`	2^24-1 (16M-1)	16777215
`LONGBLOB`	2^32-1 (4G-1)	4294967295

6.2.3.1 `CHAR` 型と `VARCHAR` 型

CHAR 型と VARCHAR 型はよく似ていますが格納、取り出しの手順に違いがあります。

CHAR フィールドの長さはテーブルを生成するときに宣言した長さに固定されます。長さは 1 から 255 までの値を取ります。CHAR が格納されるときには指定された長さになるように右側に空白が詰められます。CHAR の値が取り出された場合には右側(後続)の空白は取り除かれます。

VARCHAR フィールドの値は可変長文字列です。 VARCHAR フィールドは CHAR フィールドと同じく 1 から 255 までの長さに宣言できます。 (MySQL バージョン 3.23 では, CHAR の長さは 0 から 255 まで許されています.) しかし CHAR 型と異なり VARCHAR 型の値は必要な文字数の分に長さを記録する1 バイトを足した領域に格納されます。値には桁合わせのための空白はつけられません。後続の空白は値の格納時に取り除かれます。(この空白の除去は ANSI SQL仕様とは違っています。)

もし CHAR または VARCHAR フィールドに、フィールドの最大長を越える長さの値を与えた場合は、適合するように切り詰められます。

以下の表はこれらの二つのフィールド型の違いを、CHAR(4) および VARCHA R(4) に様々な文字列値を格納した結果を示すことで表しています。

値	`CHAR(4)`	必要な格納域	@code {VARCHAR(4)}	必要な格納域
`''`	`' '`	4 バイト	`''`	1 バイト
`'ab'`	`'ab '`	4 バイト	`'ab'`	3 バイト
`'abcd'`	`'abcd'`	4 バイト	`'abcd'`	5 バイト
`'abcdefgh'`	`'abcd'`	4 バイト	`'abcd'`	5 バイト

CHAR(4) フィールドの後続の空白は取り出し時にとりのぞかれるので、CHAR(4)および VARCHAR(4) から取り出される値はどの場合でも同じです。

CHAR および VARCHAR フィールドの値はテーブルの生成時に BINARY 属性がつけられない限り、大文字と小文字を区別しないでソート・比較されます。BINARY 属性はその列の値が大文字、小文字を区別して、MySQLサーバを実行しているマシンのASCII順にソート・比較されることを意味します。 BINARY はフィールドがどのように格納されるか、どのように取り出されるかには影響しません。

BINARY 属性は「固定的」です。つまり、もし BINARY であると指定されたフィールドが式の中にあると式全体が BINARY の値として比較されるのです。

MySQL はテーブル生成時に何も断らずにCHAR または VARCHAR 型のフィールドを変更する事があります。「6.5.3.1 暗黙のフィールド定義変更」節参照.

6.2.3.2 `BLOB` と `TEXT` 型

BLOB は大きなバイナリ型のオブジェクトで、可変長のデータを保持できます。 4 つの BLOB 型、すなわち TINYBLOB, BLOB, MEDIUMBLOB と LONGBLOB は保持できるデータの最大長が違うだけです。「6.2.6 各フィールド型の所要容量」節参照.

4 つの TEXT 型、すなわち TINYTEXT, TEXT, MEDIUMTEXT と LONGTEXT は 4 つの BLOB 型に対応し、同じ最大長と格納条件を持っています。 TEXT と BLOB の違いは、 TEXT はケースに依存しないでソートと比較され、 BLOB はケースに依存して(文字コードで)比較されることだけです。いうならば、TEXT は、ケースに依存しない BLOB です。

もし BLOB や TEXT フィールドにそれらの最大長以上の値が与えられた場合、その値はきっちり収まるように切り落とされます。

ほとんどの点で、TEXT フィールドを VARCHAR の大きい物と見なすことが出来ます。同様に、BLOB フィールドは VARCHAR BINARY フィールドの大きくなった物です。違いは、

MySQL バージョン 3.23.2 以上では、BLOB と TEXT 項にインデックスを持つことが出来ます。それ以前のバージョンではインデックスをもつことが出来ません。
VARCHAR フィールドで行っているようには、BLOB と TEXT フィールドの値の後ろについている連続した空白文字は切り落とされません。
BLOB と TEXT 項は DEFAULT 値を持つことが出来ません。

MyODBC は BLOB を LONGVARBINARY として、 TEXT を LONGVARCHAR として定義します。

BLOB と TEXT フィールドは極端に長いので、それらを使用する際には、いくつかの困った事にでくわすかもしれません：

もし GROUP BY か ORDER BY を BLOB フィールドや TEXT フィールドで使用したいなら、フィールドの値を固定長のものに変換しなくてはなりません。標準的な方法は、 SUBSTRING 関数を使用することです。たとえば：
```
mysql> SELECT comment FROM tbl_name,SUBSTRING(comment,20) AS substr
    ->                 ORDER BY substr;
```
もしこれをしない場合、フィールドの最初の max_sort_length バイトがソート時に使用されます。 max_sort_length のデフォルト値は 1024; この値は mysqld サーバー起動時に -O オプションを使用することで変更できます。フィールドの位置を指定することによってか、エイリアスを使用することによって、 BLOB や TEXT の値で group 化できます。
```
mysql> SELECT id,SUBSTRING(blob_col,1,100) FROM tbl_name GROUP BY 2;
mysql> SELECT id,SUBSTRING(blob_col,1,100) AS b FROM tbl_name GROUP BY b;
```
BLOB または TEXT オブジェクトの最大長はその型により決定されますが、あなたがクライアントとサーバの間で実際に送ることができるは最大長は、利用可能なメモリ量とコミュニケーションバッファのサイズによって決定されます。メッセージバッファサイズを変えることができますが、その場合、サーバーとクライアント、両方共に変更しなければなりません。「5.5.2 サーバーパラメーターのチューニング」節参照.

それぞれの BLOB, TEXT フィールドは、一意のアロケートされたオブジェクトによって、内部では表されることに注意してください.。これはテーブルが開かれるときに一度だけアロケートされる他のフィールドとは対照的です。

6.2.3.3 `ENUM` 型

ENUM はストリングオブジェクトで、その値は、通常、テーブル作成時のフィールド定義で列挙された値の中から選ばれます。

値はある状況下では空文字 ("") か NULL を取ることがあります：

もし ENUM に無効な値 (列挙されている値の中に含まれない文字) を代入した場合、そのエラーになる文字の代わりに空文字が挿入されます。
もし ENUM が NULL と定義された場合, NULL はそのフィールドで許可される値となり、デフォルト値が NULL になります。もし ENUM が NOT NULL と定義されたならば、デフォルト値は、列挙リストの最初の値になります。

列挙されたそれぞれの値はインデックスを持ちます：

列挙リストの要素は 1 から付番されます。
空文字エラーのインデックス値は 0 。これは不正な ENUM 値が与えられているレコードを見つけるために以下のような SELECT 構文が使用できることを意味します：
```
mysql> SELECT * FROM tbl_name WHERE enum_col=0;
```
NULL のインデックス値は NULL.

たとえば、フィールドが ENUM("one", "two", "three") と定義されたなら、以下に示す値をとります。それぞれのインデックス値も示します。

値	インデックス
`NULL`	`NULL`
`""`	0
`"one"`	1
`"two"`	2
`"three"`	3

列挙は最大 65535 個の要素まで可能です。

Starting from 3.23.51 trailing spaces are automatically deleted from ENUM values when the table is created.

ENUM フィールドに値を与える場合は大文字小文字は無関係です。しかし、後でフィールドから検索される値は、大文字小文字をもちます。これはテーブル作成時に与えられたリストの値です。

もし ENUM を数値の文脈で検索した場合、そのメンバーを前から数えた時の順番が数値で返ってきます。たとえば、ENUM フィールドから次のようにして数値を取り出すことができます:

mysql> SELECT enum_col+0 FROM tbl_name;

もし ENUM に数値を代入しようとした場合、その数値の位置にあるメンバーが代入されます。 (しかし、これは LOAD DATA では働きません。これはすべての入力を文字列として扱います。) It's not advisable to store numbers in an ENUM string because it will make things confusing.

ENUM 値は列挙メンバがフィールド指定にリストされた順に従ってソートされます。(つまり、ENUM 値はインデックス値に従ってソートされます。) 例えば、ENUM("a", "b") ならば "a" が "b" の前にソートされ、 ENUM("b", "a") ならば "b" が "a" の前にソートされます。空文字列は空ではない文字の前にソートされ、 NULL は他の列挙の前に並びます。 To prevent unexpected results, specify the ENUM list in alphabetical order. You can also use GROUP BY CONCAT(col) to make sure the column is sorted alphabetically rather than by index number.

ENUM フィールドで指定可能な値のリストを全て取りたいならば、次のようにします： SHOW COLUMNS FROM table_name LIKE enum_column_name そして二番目のフィールドの ENUM 定義を分析します。

6.2.3.4 `SET` 型

SET は文字型オブジェクトでゼロかそれ以上を値持ちます。テーブル作成時には、それぞれの値はリストから選ばれるべきです。 SET 型のフィールドの値は、コンマ(`,') 区切りで並べられた複数のメンバーで構成されています。これは、 SET メンバーの値中にコンマを含むことが出来ない、ということです。

例えば、 SET("one", "two") NOT NULL と指定されたフィールドは以下の値をとります：

""
"one"
"two"
"one,two"

SET は最大 64 個の異なったメンバーがもてます。

Starting from 3.23.51 trailing spaces are automatically deleted from SET values when the table is created.

MySQL は SET の値を数値として代入します。代入された値の最下位のビットが最初のメンバーに対応します。もし SET 値を数値の文脈で検索した場合、検索される値はフィールドの値に対応します。たとえば、SET フィールドから次のようにして数値を取り出すことができます:

mysql> SELECT set_col+0 FROM tbl_name;

もし数値が SET フィールドに代入された場合、二進数で表される数値のビットによって、メンバーが決定されます。 SET("a","b","c","d") とフィールドが定義されたとします。メンバーは以下の２進数の値を持ちます：

`SET` member	10進数	２進数値
`a`	`1`	`0001`
`b`	`2`	`0010`
`c`	`4`	`0100`
`d`	`8`	`1000`

もしこのフィールドに 9 を与えた場合、これは２進数で 1001 ですから、 1 番目と 4 番目の SET メンバーである "a" と "d" が選択され、結果、 "a,d" となります。

1つ以上の SET 要素を含む値においては,あなたが値を挿入するとき,要素がどんな順序で記載されているのかは重要ではありません. また,何回要素が与えられたのかは重要ではありません. 後で値が検索されるとき, 値の中のそれぞれの要素はただ一回だけ表れます。そのとき、テーブル作成時に与えられた順に要素は並びます。例えば、フィールドが SET("a","b","c","d") と設定されていたなら、 "a,d", "d,a", "d,a,a,d,d" は検索されると "a,d" となります。

If you set a SET column to an unsupported value, the value will be ignored.

SET 値は数値として代入されます。 NULL 値は非 NULL SET 値の前にソートされます。

通常、LIKE か FIND_IN_SET() を使用して SET フィールドの SELECT を行います：

mysql> SELECT * FROM tbl_name WHERE set_col LIKE '%value%';
mysql> SELECT * FROM tbl_name WHERE FIND_IN_SET('value',set_col)>0;

しかし、以下も動作します：

mysql> SELECT * FROM tbl_name WHERE set_col = 'val1,val2';
mysql> SELECT * FROM tbl_name WHERE set_col & 1;

最初の文は完全一致するものを探します。二つ目は第一番目のメンバーを含む値を探します。

もし SET フィールドで設定可能なすべてのメンバーを知りたい場合： SHOW COLUMNS FROM table_name LIKE set_column_name とし、２番目にあらわされる SET 定義を分析します。

6.2.4 正しいフィールド型の選択

もっとも効率よく格納するには、全てにおいて一番正確な型を使用することです。例えば、1-99999 の整数には、MEDIUMINT UNSIGNED が最良の型です。

良くある問題は、貨幣の値の正確な表現です。MySQL では DECIMAL 型を使用すべきです。これは文字列として格納し、正確さのロスは発生しません。正確さが重要でない場合は DOUBLE 型でも十分良いです。

高精度のため、常に BITINT に格納される固定小数点型に変換できます。これは、全ての計算を整数で行なうようにし、結果だけを浮動小数点に変換して戻します。

6.2.5 他のデータベースエンジンのフィールド型の使用

ほかのベンダーからSQLを簡単に書けれるように、 MySQL は以下の表にしめすフィールド型をサポートします。これらは、テーブルの定義を、他のデータベースエンジンから MySQL に簡単に移行させてくれます：

Other vendor type	MySQL type
`BINARY(NUM)`	`CHAR(NUM) BINARY`
`CHAR VARYING(NUM)`	`VARCHAR(NUM)`
`FLOAT4`	`FLOAT`
`FLOAT8`	`DOUBLE`
`INT1`	`TINYINT`
`INT2`	`SMALLINT`
`INT3`	`MEDIUMINT`
`INT4`	`INT`
`INT8`	`BIGINT`
`LONG VARBINARY`	`MEDIUMBLOB`
`LONG VARCHAR`	`MEDIUMTEXT`
`MIDDLEINT`	`MEDIUMINT`
`VARBINARY(NUM)`	`VARCHAR(NUM) BINARY`

もし他のベンダーの型を使用してテーブルを作ろうとすると、テーブル作成時のフィールドの型のマッピングが発生し、 DESCRIBE tbl_name 構文を発行します。そして MySQL は、使用された型と等価な MySQL の型を用いてテーブルを構成したことを告げます。

6.2.6 各フィールド型の所要容量

MySQLがサポートする各フィールドタイプ毎の所要容量を、カテゴリ別に以下に記述します。

6.2.6.1 数値タイプの保存容量

フィールドタイプ	所要容量
`TINYINT`	1 byte
`SMALLINT`	2 bytes
`MEDIUMINT`	3 bytes
`INT`	4 bytes
`INTEGER`	4 bytes
`BIGINT`	8 bytes
`FLOAT(X)`	X <= 24 の場合 4、25 <= X <= 53 の場合 8
`FLOAT`	4 bytes
`DOUBLE`	8 bytes
`DOUBLE PRECISION`	8 bytes
`REAL`	8 bytes
`DECIMAL(M,D)`	D > 0 の場合 `M+2`, D = 0 の場合 `M+1` bytes (`M < D` の場合 `D`+2)
`NUMERIC(M,D)`	D > 0 の場合 `M+2`, D = 0 の場合 `M+1` bytes (`M < D` の場合 `D`+2)

6.2.6.2 日付と時間タイプの保存容量

フィールドタイプ	所要容量
`DATE`	3 bytes
`DATETIME`	8 bytes
`TIMESTAMP`	4 bytes
`TIME`	3 bytes
`YEAR`	1 byte

6.2.6.3 文字列タイプの保存容量

フィールドタイプ	所要容量
`CHAR(M)`	`M` bytes, `1 <= M <= 255`
`VARCHAR(M)`	`L`+1 bytes, where `L <= M` and `1 <= M <= 255`
`TINYBLOB`, `TINYTEXT`	`L`+1 bytes,where `L` < 2^8
`BLOB`, `TEXT`	`L`+2 bytes,where `L` < 2^16
`MEDIUMBLOB`, `MEDIUMTEXT`	`L`+3 bytes,where `L` < 2^24
`LONGBLOB`, `LONGTEXT`	`L`+4 bytes,where `L` < 2^32
`ENUM('value1','value2',...)`	1 or 2 bytes, 列挙値の数に依存 (最大値は 65535 )
`SET('value1','value2',...)`	1, 2, 3, 4 or 8 bytes, 要素の数に依存 (最大要素 64 )

VARCHAR、BLOB、及びTEXT型は可変長型であり、所要容量は、フィールドのとり得る最大サイズというよりはむしろフィールド値の実際の長さに依存します (前の表でLと表しました)。例えば、VARCHAR(10)フィールドは、最大10文字分の長さの文字列を保持することが出来ます。実際の所要容量は、文字列の長さ(L)と、その長さを記録するための１バイトを加えます。文字列'abcd'においては、Lは４で、所要容量は５バイトです。

BLOBとTEXT型は、フィールド値の長さを記録するのに、１、２、３、又は４バイト必要とし、型のとり得る最大の長さに依存します。「6.2.3.2 BLOB と TEXT 型」節参照.

テーブルが可変長フィールド型を含む場合、そのレコードフォーマットもまた可変長となるでしょう。テーブルが作成された時、MySQLは確かな条件の下、フィールドを可変長タイプから固定長タイプへ変更し、副作用を起こすことに注意して下さい。「6.5.3.1 暗黙のフィールド定義変更」節参照.

ENUMオブジェクトのサイズは、異なる列挙値の数によって決められます。列挙する数が255以内では、１バイトが使用されます。列挙する数が65535以内では、２バイトが使用されます。「6.2.3.3 ENUM 型」節参照.

SETオブジェクトのサイズは、異なる要素の数によって決められます。組のサイズをNとすると、オブジェクトは(N+7)/8バイトを占有し、１、２、３、４又は８バイトに切上げられます。１つのSETは、最大６４要素を持つことができます。「6.2.3.4 SET 型」節参照.

6.3 `SELECT` と `WHERE` 節で使用する関数

SQL ステートメント中の select_expression または where_definition は後述の関数を使用した任意の式からなります。

演算と関数を式の中で呼ぶ時、本ドキュメントに示しているもの以外の、 NULL を含む式は常に NULL 値を生成します

注意: 関数名とそれに続く語句の間には、空白はありません。これは関数の呼び出しと、関数と同名のテーブル(かフィールド)の参照を、 MySQL パーサが区別するのを助けます。

mysqld に --ansi をつけて起動するか、 CLIENT_IGNORE_SPACE を mysql_connect() に使用すれば、 MySQL が関数名の後の空白を許すようになりますが、その場合、すべての関数名が予約語になります。「1.7.2 MySQLをANSIモードで実行する」節参照。

次の例では、mysql プログラムの出力は短くなっています。つまり:

mysql> SELECT MOD(29,9);
1 rows in set (0.00 sec)

+-----------+
| mod(29,9) |
+-----------+
|         2 |
+-----------+

これは次に変換されています:

mysql> SELECT MOD(29,9);
        -> 2

6.3.1 Non-Type-Specific Operators and Functions

The maximum size of a row in a MyISAM table is 65534 bytes. Each BLOB and TEXT column accounts for only 5-9 bytes towards this size.

6.3.1.1 Parentheses

( ... )

Use parentheses to force the order of evaluation in an expression. For example:

mysql> SELECT 1+2*3;
        -> 7
mysql> SELECT (1+2)*3;
        -> 9

6.3.1.2 比較演算子

1 (TRUE), 0 (FALSE) または NULL を返します。これらの関数は数値と文字列の両方で働きます。必要ならば、文字は自動的に数字に変換され、数字は文字に変換されます。 (Perlがおこなっているみたいに)

MySQL は以下の規則で比較を行います：

どちらかまたは両方の引数が NULL の場合は、比較結果は NULL です。<=> 演算子を除きます。
比較操作の両方の引数が文字列の場合、文字列として比較されます。
両方の引数が整数の場合、整数として比較されます。
16進数の値は、もし数値と比較されないのであれば、文字列として扱われます。
引数の一方が TIMESTAMP または DATETIME フィールドで、他の引数が定数の場合は、定数は比較前に timestamp に変換されます。これはより ODBC フレンドリにするためです。
他の場合は全て浮動小数点(real)として比較されます。

文字列の比較は、ケースに依存せず、標準のキャラクターセットに従って行われます。(ISO-8859-1 Latin1 がデフォルトです。これは English です)

以下は、比較のために文字が数値へ変換されている例です：

mysql> SELECT 1 > '6x';
         -> 0
mysql> SELECT 7 > '6x';
         -> 1
mysql> SELECT 0 > 'x6';
         -> 0
mysql> SELECT 0 = 'x6';
         -> 1

=

等しい:

mysql> SELECT 1 = 0;
        -> 0
mysql> SELECT '0' = 0;
        -> 1
mysql> SELECT '0.0' = 0;
        -> 1
mysql> SELECT '0.01' = 0;
        -> 0
mysql> SELECT '.01' = 0.01;
        -> 1

<>

!=

等しくない:

mysql> SELECT '.01' <> '0.01';
        -> 1
mysql> SELECT .01 <> '0.01';
        -> 0
mysql> SELECT 'zapp' <> 'zappp';
        -> 1

<=

より小さいか等しい:

mysql> SELECT 0.1 <= 2;
        -> 1

<

より小さい:

mysql> SELECT 2 < 2;
        -> 0

>=

より大きいか等しい:

mysql> SELECT 2 >= 2;
        -> 1

>

より大きい:

mysql> SELECT 2 > 2;
        -> 0

<=>

等しい(NULL 安全):

mysql> SELECT 1 <=> 1, NULL <=> NULL, 1 <=> NULL;
        -> 1 1 0

IS NULL

IS NOT NULL

値が NULL とであるかどうかのテスト:

mysql> SELECT 1 IS NULL, 0 IS NULL, NULL IS NULL;
        -> 0 0 1
mysql> SELECT 1 IS NOT NULL, 0 IS NOT NULL, NULL IS NOT NULL;
        -> 1 1 0

To be able to work good with other programs, MySQL supports the following extra features when using IS NULL:

You can find the last inserted row with:
```
SELECT * FROM tbl_name WHERE auto_col IS NULL
```
This can be disabled by setting SQL_AUTO_IS_NULL=0. 「5.5.6 SET 構文」節参照.
For NOT NULL DATE and DATETIME columns you can find the special date 0000-00-00 by using:
```
SELECT * FROM tbl_name WHERE date_column IS NULL
```
This is needed to get some ODBC applications to work (as ODBC doesn't support a 0000-00-00 date)

expr BETWEEN min AND max

もし expr が min 以上、 max 以下なら 1を返します。そうでないなら 0 を返します。これは全ての引数が同じ型ならば、(min <= expr AND expr <= max) と同じです。 Otherwise type conversion takes place, according to the rules above, but applied to all the three arguments. Note that before 4.0.5 arguments were converted to the type of expr instead.

mysql> SELECT 1 BETWEEN 2 AND 3;
        -> 0
mysql> SELECT 'b' BETWEEN 'a' AND 'c';
        -> 1
mysql> SELECT 2 BETWEEN 2 AND '3';
        -> 1
mysql> SELECT 2 BETWEEN 2 AND 'x-3';
        -> 0

expr NOT BETWEEN min AND max

Same as NOT (expr BETWEEN min AND max).

expr IN (value,...)

もし expr が IN リストにある値のどれかならば、1 を返します。そうでなければ 0 を返します。もし全ての値が定数なら、すべての値が expr の型に従って評価され、ソートされます。この検索にはバイナリサーチが使用されます。これは IN リストに定数を与えた場合、IN が速くなることを意味します。もし expr がケース依存の文字式なら、ケース依存のやり方で比較されます。

mysql> SELECT 2 IN (0,3,5,'wefwf');
        -> 0
mysql> SELECT 'wefwf' IN (0,3,5,'wefwf');
        -> 1

From 4.1 (in line with the SQL-99 standard), IN returns NULL not only if the expression on the left hand side is NULL, but also if no match is found in the list and one of the expressions in the list is NULL.

expr NOT IN (value,...)

NOT (expr IN (value,...)) と同じ。

ISNULL(expr)

expr が NULL なら 1 を、そうでなければ 0 を返します

mysql> SELECT ISNULL(1+1);
        -> 0
mysql> SELECT ISNULL(1/0);
        -> 1

NULL の値を = を使用して比較した場合は常に偽(false) となることに注意してください！

COALESCE(list)

list 中の、最初に現れた非-NULL 要素を返します。

mysql> SELECT COALESCE(NULL,1);
        -> 1
mysql> SELECT COALESCE(NULL,NULL,NULL);
        -> NULL

INTERVAL(N,N1,N2,N3,...)

もし N < N1 なら 0 を返します。もし N < N2 なら 1 を返します。全ての引数は整数として扱われます。これは N1 < N2 < N3 < ... < Nnを正しく動作させるために必要なことです。これはバイナリ検索が使用されます(速いです)

mysql> SELECT INTERVAL(23, 1, 15, 17, 30, 44, 200);
        -> 3
mysql> SELECT INTERVAL(10, 1, 10, 100, 1000);
        -> 2
mysql> SELECT INTERVAL(22, 23, 30, 44, 200);
        -> 0

If you are comparing case-insensitive strings with any of the standard operators (=, <>..., but not LIKE) trailing whitespace (spaces, tabs and newlines) will be ignored.

mysql> SELECT "a" ="A \n";
        -> 1

6.3.1.3 論理演算

全ての論理関数は 1 (TRUE) か 0 (FALSE) か NULL を返します。 (unknown は多くの場合 FALSE と同じです)：

NOT

!

論理否定。引数が 0 なら 1 を返し、そうでなければ 0 を返します。例外: NOT NULL は NULL を返します:

mysql> SELECT NOT 1;
        -> 0
mysql> SELECT NOT NULL;
        -> NULL
mysql> SELECT ! (1+1);
        -> 0
mysql> SELECT ! 1+1;
        -> 1

最後の例は 1 を返します。なぜなら、式の評価が (!1)+1 と同じだからです。

AND

&&

論理積。全ての引数が非0 または非NULL であれば 1 を返します。引数のどれかが 0 ならば 0 を返します。それ以外は NULL を返します。

mysql> SELECT 1 && 1;
        -> 1
mysql> SELECT 1 && 0;
        -> 0
mysql> SELECT 1 && NULL;
        -> NULL
mysql> SELECT 0 && NULL;
        -> 0
mysql> SELECT NULL && 0;
        -> 0

Please note that MySQL versions prior to 4.0.5 stop evaluation when a NULL is encountered, rather than continuing the process to check for possible 0s. This means that in these versions, SELECT (NULL AND 0) returns NULL instead of 0. In 4.0.5 the code has been re-engineered so that the result will always be as prescribed by ANSI while still using the optimisation wherever possible.

OR

||

論理和。 Evaluates to 1 if any operand is non-zero, to NULL if any operand is NULL, otherwise 0 is returned.

mysql> SELECT 1 || 1;
        -> 1
mysql> SELECT 1 || 0;
        -> 1
mysql> SELECT 0 || 0;
        -> 0
mysql> SELECT 0 || NULL;
        -> NULL
mysql> SELECT 1 || NULL;
        -> 1

XOR

Logical XOR. Returns NULL if either operand is NULL. For non-NULL operands, evaluates to 1 if an odd number of operands is non-zero, otherwise 0 is returned.

mysql> SELECT 1 XOR 1;
        -> 0
mysql> SELECT 1 XOR 0;
        -> 1
mysql> SELECT 1 XOR NULL;
        -> NULL
mysql> SELECT 1 XOR 1 XOR 1;
        -> 1

a XOR b is mathematically equal to (a AND (NOT b)) OR ((NOT a) and b). XOR was added in version 4.0.2.

6.3.1.4 フロー制御関数

IFNULL(expr1,expr2)

expr1 が NULL でない場合は expr1 を、そうでなければ expr2 を返します。 IFNULL() はどの文脈で使用されたかにより数値か文字を返します:

mysql> SELECT IFNULL(1,0);
        -> 1
mysql> SELECT IFNULL(NULL,10);
        -> 10
mysql> SELECT IFNULL(1/0,10);
        -> 10
mysql> SELECT IFNULL(1/0,'yes');
        -> 'yes'

In 4.0.6 and above the default result value of IFNULL(expr1,expr2) is the more 'general' of the two expressions, in the order STRING, REAL or INTEGER.The difference to earlier MySQL versions are mostly notable when you create a table based on expressions or MySQL has to internally store a value from IFNULL() in a temporary table.

CREATE TABLE foo SELECT IFNULL(1,"test") as test;

In MySQL 4.0.6 the type for column 'test' is CHAR(4) while in earlier versions you would get BIGINT.

NULLIF(expr1,expr2)

expr1 = expr2 が真なら、NULL を返し、そうでなければ expr1 を返します。これは CASE WHEN x = y THEN NULL ELSE x END と同じです:

mysql> SELECT NULLIF(1,1);
        -> NULL
mysql> SELECT NULLIF(1,2);
        -> 1

注意: 引数が等しくない場合、expr1 は MySQL 内部では2回評価されます。

IF(expr1,expr2,expr3)

expr1 が真 (expr1 <> 0 and expr1 <> NULL) の場合 expr2 を返し、そうでなければ expr3 を返します。 IF() はどの文脈で使用されたかにより数値か文字を返します:

mysql> SELECT IF(1>2,2,3);
        -> 3
mysql> SELECT IF(1<2,'yes','no');
        -> 'yes'
mysql> SELECT IF(STRCMP('test','test1'),'no','yes');
        -> 'no'

If expr2 or expr3 is explicitely NULL then the result type of the IF() function is the type of the not NULL column. (This behaviour is new in MySQL 4.0.3). expr1 は INTEGER として評価されます。これは浮動小数点を使用する場合、比較演算も使用すべきであることを意味します:

mysql> SELECT IF(0.1,1,0);
        -> 0
mysql> SELECT IF(0.1<>0,1,0);
        -> 1

上の最初の例では、 IF(0.1) は 0 を返します。なぜなら 0.1 は整数値として変換され IF(0) になり、それをもとにしたテスト結果が返るからです。これはあなたの期待に添わないかもしれません。二番目の場合、比較は、元の浮動小数点値が非ゼロかどうかテストします。比較結果は整数として使用されます。 IF() のデフォルトの戻り値型(一時テーブルに格納される時に問題となります)は MySQL バージョン 3.23 では次のように計算されます:

Expression	Return value
expr2 または expr3 が文字列を返す	文字列
expr2 または expr3 が浮動小数点値を返す	浮動小数点
expr2 または expr3 が整数を返す	整数

If expr2 and expr3 are strings, then the result is case-insensitive if both strings are case-insensitive. (Starting from 3.23.51)

CASE value WHEN [compare-value] THEN result [WHEN [compare-value] THEN result ...] [ELSE result] END

CASE WHEN [condition] THEN result [WHEN [condition] THEN result ...] [ELSE result] END

最初の式は value=compare-value ならば result を返します。二つ目の式では、最初の条件[condition] が真ならば、 result を返します。もしマッチする result の値がなければ、 ELSE 以下の result が返ります。もし ELSE 部分がなければ、 NULL が返ります:

mysql> SELECT CASE 1 WHEN 1 THEN "one"
           WHEN 2 THEN "two" ELSE "more" END;
       -> "one"
mysql> SELECT CASE WHEN 1>0 THEN "true" ELSE "false" END;
       -> "true"
mysql> SELECT CASE BINARY "B" WHEN "a" THEN 1 WHEN "b" THEN 2 END;
       -> NULL

戻り値の型(INTEGER, DOUBLE, STRING)は最初に返される値 (最初の THEN の後の式)の型と同じです。

6.3.2 文字列関数

サーバー側のパラメター max_allowed_packet よりも結果の長さが大きい場合、文字列関数は NULL を返します。「5.5.2 サーバーパラメーターのチューニング」節参照.

文字の位置を扱う関数においては、一番最初の位置は数字の 1 です。

ASCII(str)

str の左端の文字の ASCII コード値を返します。 str が空文字の場合は 0 を返します。 str が NULL の場合は NULL を返します:

mysql> SELECT ASCII('2');
        -> 50
mysql> SELECT ASCII(2);
        -> 50
mysql> SELECT ASCII('dx');
        -> 100

6.3.2.1 String Comparison Functions

MySQL は必要とあらば数値を文字列に変換します。逆も同様に行います：

mysql> SELECT 1+"1";
        -> 2
mysql> SELECT CONCAT(2,' test');
        -> '2 test'

明示的に数値を文字列に変換したければ、CONCAT() に引数として渡して下さい。

文字列関数は引数としてバイナリ文字列が与えられると、結果の文字列もバイナリ文字列になります。文字列に変換された数値はバイナリ文字列とみなされます。これは比較にだけ影響します。

通常、比較される表現がケース依存でない場合、比較はケース非依存で行われます。

expr LIKE pat [ESCAPE 'escape-char']

SQL の簡単な正規表現比較です。1 (TRUE) または 0 (FALSE) を返します。 LIKE には2つのワイルドカードがあります:

Char	Description
`%`	任意の数の文字(0文字も含む)に適合します。
`_`	厳密に1つの文字に適合します。

mysql> SELECT 'David!' LIKE 'David_';
        -> 1
mysql> SELECT 'David!' LIKE '%D%v%';
        -> 1

ワイルドカード文字のテストをするためには、エスケープ文字より先行しておこなってください。 ESCAPE を指定しない場合は、文字 `\' が使われます:

String	Description
`\%`	1つの `%` に適合します。
`\_`	1つの `_` に適合します。

mysql> SELECT 'David!' LIKE 'David\_';
        -> 0
mysql> SELECT 'David_' LIKE 'David\_';
        -> 1

違うエスケープ文字を指定するには、 ESCAPE 節を使用します:

mysql> SELECT 'David_' LIKE 'David|_' ESCAPE '|';
        -> 1

次の２つのステートメントは、オペランドの一つがバイナリ文字列でなければ、文字列比較がケース非依存であることを示しています:

mysql> SELECT 'abc' LIKE 'ABC';
        -> 1
mysql> SELECT 'abc' LIKE BINARY 'ABC';
        -> 0

LIKE は数値表現でも許されます！ (これは MySQL の、ANSI SQL LIKE に対する拡張です) 注意： MySQL は文字列中に C のエスケープ文字を使用しているので(e.g., `\n'), LIKE の指定文字列として使用するには `\' を二倍しなくてはなりません。例えば、 `\n' を探すには、`\\n' と記述します。 `\' を探すには、 `\\\\' (バックスラッシュは、一つはパーサーに取り除かれ、パターンマッチが行われる際にもうひとつ取り除かれ、一致を探すために残った一つのバックスラッシュが使用されます)

expr NOT LIKE pat [ESCAPE 'escape-char']

NOT (expr LIKE pat [ESCAPE 'escape-char']) と同じ

expr SOUNDS LIKE expr

Same as SOUNDEX(expr)=SOUNDEX(expr) (available only in version 4.1 or later).

expr REGEXP pat

expr RLIKE pat

パターン pat に対し、文字式 expr のパターンマッチを行います。パターン pat は正規表現の拡張が使用できます。「G MySQL の正規表現」節参照. もし expr が pat にマッチするなら 1 を返し、でなければ 0 を返します。 RLIKE は REGEXP と同義で、mSQL 互換を提供します。注意: MySQL は C エスケープ構文を文字中に使用しており(\n)、 REGEXP 中で使用される '\' 文字はすべて、二重に書かなければなりません。 MySQL 3.23.4 REGEXP は、普通の文字 (not binary) はケース非依存です:

mysql> SELECT 'Monty!' REGEXP 'm%y%%';
        -> 0
mysql> SELECT 'Monty!' REGEXP '.*';
        -> 1
mysql> SELECT 'new*\n*line' REGEXP 'new\\*.\\*line';
        -> 1
mysql> SELECT "a" REGEXP "A", "a" REGEXP BINARY "A";
        -> 1  0
mysql> SELECT "a" REGEXP "^[a-d]";
        -> 1

REGEXP and RLIKE は、文字の型を決定する場合、カレントのキャラクターセットを使用します。 (ISO-8859-1 Latin1 がデフォルト)

expr NOT REGEXP pat

expr NOT RLIKE pat

NOT (expr REGEXP pat) と同じ.

STRCMP(expr1,expr2)

STRCMP() 文字列が同じなら 0 を返します。そうでなければ、最初の引数がソート順で小さければ -1 を返します。そうでなければ 1 を返します:

mysql> SELECT STRCMP('text', 'text2');
        -> -1
mysql> SELECT STRCMP('text2', 'text');
        -> 1
mysql> SELECT STRCMP('text', 'text');
        -> 0

MATCH (col1,col2,...) AGAINST (expr)

MATCH ... AGAINST() は全文検索に使用され、妥当性を返します。フィールド (col1,col2,...) 内のテキストとクエリ expr との間の類似点を評価します。妥当性は正の浮動小数点数です。妥当性 0 は類似点なしを意味します。MATCH ... AGAINST() が動作するためには、最初に FULLTEXT インデックスが作成する必要があります。「6.5.3 CREATE TABLE 構文」節参照。 MATCH ... AGAINST() は MySQL 3.23.23 以上のバージョンで有効です。 IN BOOLEAN MODE extension was added in version 4.0.1. 詳細と使用例は「6.8 MySQL Full-text Search」節.

6.3.2.2 Case-Sensitivity

BINARY

BINARY 演算子は、これ以降に続く文字をバイナリにキャストします。これはたとえフィールドが BINARY や BLOB 定義でなくても、ケース依存でフィールドを比較することが出来る簡単な方法です:

mysql> SELECT "a" = "A";
        -> 1
mysql> SELECT BINARY "a" = "A";
        -> 0

BINARY string is a shorthand for CAST(string AS BINARY). 「6.3.5 Cast Functions」節参照. BINARY は MySQL 3.23.0 で登場しました。注意: いくつかの文脈では、インデックスされたフィールドを BINARY にキャストした時、MySQL はインデックスを効率よく使用できません。

BLOB をケース非依存で比較したい場合、比較を行なう前に BLOB を常に大文字に変換します:

SELECT 'A' LIKE UPPER(blob_col) FROM table_name;

より柔軟に文字列を比較するために、我々は間もなく異なる文字セット間のキャストを導入する予定です。

6.3.3 Numeric Functions

6.3.3.1 算術演算

普通の算術演算が有効です。 -, +, * は、二つの引数が正数ならば BIGINT (64bit精度) で計算されることに注意してください！ If one of the argument is an unsigned integer, and the other argument is also an integer, the result will be an unsigned integer. 「6.3.5 Cast Functions」節参照.

+

足し算:

mysql> SELECT 3+5;
        -> 8

-

引き算:

mysql> SELECT 3-5;
        -> -2

*

掛け算:

mysql> SELECT 3*5;
        -> 15
mysql> SELECT 18014398509481984*18014398509481984.0;
        -> 324518553658426726783156020576256.0
mysql> SELECT 18014398509481984*18014398509481984;
        -> 0

最後の式の結果は不当です。なぜなら結果は BIGINT の 64 ビットを超えた整数だからです。

/

割り算:

mysql> SELECT 3/5;
        -> 0.60

0 で割った場合、NULL になります。

mysql> SELECT 102/(1-1);
        -> NULL

演算結果が整数になる場合にだけ、 BIGINT を用いて割り算は計算されます。

6.3.3.2 数学関数

すべての数学関数はエラーの場合 NULL を返します。

-

符号。引数の符号を変更します:

mysql> SELECT - 2;
        -> -2

このオペレーターが BIGINT とともに使用された場合、返り値は BIGINT であることに注意してください! これは -2^63 の値を持つかもしれない整数を、 - で使用してはならないことを意味します！

ABS(X)

Returns the absolute value of X:

mysql> SELECT ABS(2);
        -> 2
mysql> SELECT ABS(-32);
        -> 32

この関数は BIGINT 値とともに使用されると安全です。

SIGN(X)

X が負数、ゼロ、整数によって、 -1, 0 or 1 を返します:

mysql> SELECT SIGN(-32);
        -> -1
mysql> SELECT SIGN(0);
        -> 0
mysql> SELECT SIGN(234);
        -> 1

MOD(N,M)

%

剰余 ( C の % 演算子のような ). N を M で割ったときの余りが返ります:

mysql> SELECT MOD(234, 10);
        -> 4
mysql> SELECT 253 % 7;
        -> 1
mysql> SELECT MOD(29,9);
        -> 2

この関数は BIGINT 値でも安全に使用できます。

FLOOR(X)

X より大きくならない整数のうち、最大の整数値を返します:

mysql> SELECT FLOOR(1.23);
        -> 1
mysql> SELECT FLOOR(-1.23);
        -> -2

返り値は BIGINT に変換されていることに注意!

CEILING(X)

X より小さくならない整数のうち、最小の整数値を返します.

mysql> SELECT CEILING(1.23);
        -> 2
mysql> SELECT CEILING(-1.23);
        -> -1

返り値は BIGINT に変換されていることに注意!

ROUND(X)

X を整数に丸めた値(四捨五入)を返します:

mysql> SELECT ROUND(-1.23);
        -> -1
mysql> SELECT ROUND(-1.58);
        -> -2
mysql> SELECT ROUND(1.58);
        -> 2

引数が２つの整数間の半分時の ROUND() の振る舞いは、C ライブラリの実装に依存します。いくつかは、近い偶数値、常に上、常に下、または常に０方向に丸めます。丸めの種類の一つを必要とする場合は、TRUNCATE() または FLOOR() のようなはっきりと定義された関数を代わりに使用すべきです。

ROUND(X,D)

X を D で指定した少数桁に丸めた値(四捨五入)を返します。もし D が 0 なら, 結果は小数点無しになるか少数部分になるでしょう:

mysql> SELECT ROUND(1.298, 1);
        -> 1.3
mysql> SELECT ROUND(1.298, 0);
        -> 1

EXP(X)

指数関数 : e (自然対数の底) の X 乗:

mysql> SELECT EXP(2);
        -> 7.389056
mysql> SELECT EXP(-2);
        -> 0.135335

LN(X)

Returns the natural logarithm of X:

mysql> SELECT LN(2);
        -> 0.693147
mysql> SELECT LN(-2);
        -> NULL

This function was added in MySQL version 4.0.3. It is synonymous with LOG(X) in MySQL.

LOG(X)

LOG(B,X)

自然対数 X: If called with one parameter, this function returns the natural logarithm of X:

mysql> SELECT LOG(2);
        -> 0.693147
mysql> SELECT LOG(-2);
        -> NULL

任意の底 B に対する X の対数を得たければ、公式 LOG(X)/LOG(B) を使用してください。 If called with two parameters, this function returns the logarithm of X for an arbitary base B:

mysql> SELECT LOG(2,65536);
        -> 16.000000
mysql> SELECT LOG(1,100);
        -> NULL

The arbitrary base option was added in MySQL version 4.0.3. LOG(B,X) is equivalent to LOG(X)/LOG(B).

LOG2(X)

Returns the base-2 logarithm of X:

mysql> SELECT LOG2(65536);
        -> 16.000000
mysql> SELECT LOG2(-100);
        -> NULL

LOG2() is useful for finding out how many bits a number would require for storage. This function was added in MySQL version 4.0.3. In earlier versions, you can use LOG(X)/LOG(2) instead.

LOG10(X)

常用対数(10を底とした対数) X:

mysql> SELECT LOG10(2);
        -> 0.301030
mysql> SELECT LOG10(100);
        -> 2.000000
mysql> SELECT LOG10(-100);
        -> NULL

POW(X,Y)

POWER(X,Y)

X の Y 乗:

mysql> SELECT POW(2,2);
        -> 4.000000
mysql> SELECT POW(2,-2);
        -> 0.250000

SQRT(X)

X の非負の平方根を返します:

mysql> SELECT SQRT(4);
        -> 2.000000
mysql> SELECT SQRT(20);
        -> 4.472136

PI()

π の値を返します。デフォルトの表示桁数は 5 ですが、MySQL 内部では π に完全な倍精度を使用します。

mysql> SELECT PI();
        -> 3.141593
mysql> SELECT PI()+0.000000000000000000;
        -> 3.141592653589793116

COS(X)

コサイン X。X はラジアン:

mysql> SELECT COS(PI());
        -> -1.000000

SIN(X)

サイン X。X はラジアン:

mysql> SELECT SIN(PI());
        -> 0.000000

TAN(X)

タンジェント X。X はラジアン:

mysql> SELECT TAN(PI()+1);
        -> 1.557408

ACOS(X)

X のアークコサインを返します。これはコサインが X である値です。X が -1 から 1 の範囲にない場合は NULL を返します:

mysql> SELECT ACOS(1);
        -> 0.000000
mysql> SELECT ACOS(1.0001);
        -> NULL
mysql> SELECT ACOS(0);
        -> 1.570796

ASIN(X)

X のアークサインを返します。これはサインが X である値です。 X が -1 から 1 の範囲にない場合は NULL を返します:

mysql> SELECT ASIN(0.2);
        -> 0.201358
mysql> SELECT ASIN('foo');
        -> 0.000000

ATAN(X)

X のアークタンジェントを返します。これはタンジェントが X である値です:

mysql> SELECT ATAN(2);
        -> 1.107149
mysql> SELECT ATAN(-2);
        -> -1.107149

ATAN(Y,X)

ATAN2(Y,X)

２つの変数 X と Y のアークタンジェントを返します。両方の引数の符号が結果の象限を決定するために使用されることを除いて、Y / X のアークタンジェントの計算と同様です:

mysql> SELECT ATAN(-2,2);
        -> -0.785398
mysql> SELECT ATAN2(PI(),0);
        -> 1.570796

COT(X)

X のコタンジェントを返します:

mysql> SELECT COT(12);
        -> -1.57267341
mysql> SELECT COT(0);
        -> NULL

RAND()

RAND(N)

0 から 1.0 間のランダムな浮動小数点数値を返します。もし N に整数を与えた場合、シードとしてこの値が使用されます:

mysql> SELECT RAND();
        -> 0.9233482386203
mysql> SELECT RAND(20);
        -> 0.15888261251047
mysql> SELECT RAND(20);
        -> 0.15888261251047
mysql> SELECT RAND();
        -> 0.63553050033332
mysql> SELECT RAND();
        -> 0.70100469486881

RAND() 値を持つフィールドは ORDER BY 節で使用できません。 ORDER BY はフィールドを複数回評価するためです。しかし MySQL バージョン 3.23 では, 次が可能です: SELECT * FROM table_name ORDER BY RAND() これは

SELECT * FROM table1,table2 WHERE a=b AND c<d ORDER BY
RAND() LIMIT 1000

のセットからランダムなサンプルを得るのに便利です。注意: WHERE 節の RAND() は WHERE が実行する度に再評価されます。 RAND() is not meant to be a perfect random generator, but instead a fast way to generate ad hoc random numbers that will be portable between platforms for the same MySQL version.

LEAST(X,Y,...)

二つ以上の引数を取り、引数中、最小の値を返します。引数は以下の規則に従って比較されます：

値が INTEGER を使用しているなら、あるいは、全ての引数が整数値ならば、整数として比較します。
値が REAL として使用されているか、全ての引数が実数ならば、実数として比較します。
いかなる引数もケース依存の文字ならば、引数はケース依存文字として比較されます。
そのほかの場合、引数はケース非依存文字として比較されます:

mysql> SELECT LEAST(2,0);
        -> 0
mysql> SELECT LEAST(34.0,3.0,5.0,767.0);
        -> 3.0
mysql> SELECT LEAST("B","A","C");
        -> "A"

バージョン 3.22.5 以前の MySQL では、MIN() を LEAST の代わりに使用できます。

GREATEST(X,Y,...)

二つ以上の引数を取り、引数中、最大の値を返します。引数は LEAST の時と同じように比較されます。

mysql> SELECT GREATEST(2,0);
        -> 2
mysql> SELECT GREATEST(34.0,3.0,5.0,767.0);
        -> 767.0
mysql> SELECT GREATEST("B","A","C");
        -> "C"

バージョン 3.22.5 以前の MySQL では、MAX() を GREATEST の代わりに使用できます。

DEGREES(X)

引数 X をラジアンから度に変換して返します:

mysql> SELECT DEGREES(PI());
        -> 180.000000

RADIANS(X)

引数 X を度からラジアンに変換して返します:

mysql> SELECT RADIANS(90);
        -> 1.570796

TRUNCATE(X,D)

少数点以下 D 桁で X を切り捨てた値を返します。 D が 0 の場合、結果は小数部や微小部を持ちません:

mysql> SELECT TRUNCATE(1.223,1);
        -> 1.2
mysql> SELECT TRUNCATE(1.999,1);
        -> 1.9
mysql> SELECT TRUNCATE(1.999,0);
        -> 1
mysql> SELECT TRUNCATE(-1.999,1);
        -> -1.9

Starting from MySQL 3.23.51 all numbers are rounded towards zero. If D is negative, then the whole part of the number is zeroed out:

mysql> SELECT TRUNCATE(122,-2);
       -> 100

注意: コンピュータでは小数点数は正確な数値としては格納されず、double 値として格納されます。次の結果によってだまされるでしょう:

mysql> SELECT TRUNCATE(10.28*100,0);
       -> 1027

上記は 10.28 は実際には 10.2799999999999999 のようなものとして格納さえるために発生します。

6.3.4 日付と時刻関数

それぞれの型がもつ値の範囲と日と時間の値が記述される有効な形式については「6.2.2 日付と時間の型」節.

日付関数を使用する例: date_col が最新の30日である全てのレコードを選択します:

mysql> SELECT something FROM table
           WHERE TO_DAYS(NOW()) - TO_DAYS(date_col) <= 30;

DAYOFWEEK(date)

Returns the weekday index date の曜日を得ます (1 = 日曜日, 2 = 月曜日, ... 7 = 土曜日) これは ODBC 標準に従います:

mysql> SELECT DAYOFWEEK('1998-02-03');
        -> 3

WEEKDAY(date)

date の曜日を得ます (0 = 月曜日, 1 = 火曜日, ... 6 = 日曜日):

mysql> SELECT WEEKDAY('1998-02-03 22:23:00');
        -> 1
mysql> SELECT WEEKDAY('1997-11-05');
        -> 2

DAYOFMONTH(date)

月の日を返します (1 - 31):

mysql> SELECT DAYOFMONTH('1998-02-03');
        -> 3

DAYOFYEAR(date)

年の日を返します (1-366): 366:

mysql> SELECT DAYOFYEAR('1998-02-03');
        -> 34

MONTH(date)

月を返します (1 - 12):

mysql> SELECT MONTH('1998-02-03');
        -> 2

DAYNAME(date)

曜日の名前を返します:

mysql> SELECT DAYNAME("1998-02-05");
        -> 'Thursday'

MONTHNAME(date)

月の名前を返します:

mysql> SELECT MONTHNAME("1998-02-05");
        -> 'February'

QUARTER(date)

date についての年の四半期を返します。範囲は 1 から 4 です:

mysql> SELECT QUARTER('98-04-01');
        -> 2

WEEK(date)

WEEK(date,first)

引数が一つの場合、date についての週を返します。範囲は 0 から 53 (そう、53週の最初というのもありえます)で、日曜日が週の最初の日です。引数が二つの形式の WEEK() は、週の開始を日曜日か月曜日か指定できます。それぞれの場合の返り値は 0-53 か 1-52 です。 Here is a table for how the second arguments work:

Value	`Meaning`
0	Week starts on Sunday and return value is in range 0-53
1	Week starts on Monday and return value is in range 0-53
2	Week starts on Sunday and return value is in range 1-53
3	Week starts on Monday and return value is in range 1-53 (ISO 8601)

mysql> SELECT WEEK('1998-02-20');
        -> 7
mysql> SELECT WEEK('1998-02-20',0);
        -> 7
mysql> SELECT WEEK('1998-02-20',1);
        -> 8
mysql> SELECT WEEK('1998-12-31',1);
        -> 53

Note: in Version 4.0, WEEK(#,0) was changed to match the calendar in the USA. Note that if a week is the last week of the previous year, MySQL will return 0 if you don't use 2 or 3 as the optional argument:

mysql> SELECT YEAR('2000-01-01'), WEEK('2000-01-01',0);
        -> 2000, 0
mysql> SELECT WEEK('2000-01-01',2);
        -> 52

One could argue that MySQL should return 52 for the WEEK() function as the given date is actually the 52 second week of 1999. We decided to return 0 instead as we want the function to return 'the week number in the given year'. This makes the usage of the WEEK() function reliable when combined with other functions that extracts a date part from a date. If you would prefer to know the correct year-week, then you should use the 2 or 3 as the optional argument or use the YEARWEEK() function:

mysql> SELECT YEARWEEK('2000-01-01');
        -> 199952
mysql> SELECT MID(YEARWEEK('2000-01-01'),5,2);
        -> 52

YEAR(date)

年を返します (1000 - 9999):

mysql> SELECT YEAR('98-02-03');
        -> 1998

YEARWEEK(date)

YEARWEEK(date,first)

データの年と週を返します。第2引数は WEEK() の第2引数とまったく同じように働きます。注意: 年の最初と最後の週では、年が date 引数内の年とは異なることがあります！

mysql> SELECT YEARWEEK('1987-01-01');
        -> 198653

Note that the week number is different from what the WEEK() function would return (0) for optional arguments 0 or 1, as WEEK() then returns the week in the context of the given year.

HOUR(time)

時を返します (0 - 23):

mysql> SELECT HOUR('10:05:03');
        -> 10

MINUTE(time)

分を返します (0-59):

mysql> SELECT MINUTE('98-02-03 10:05:03');
        -> 5

SECOND(time)

秒を返します (0 to 59)

mysql> SELECT SECOND('10:05:03');
        -> 3

PERIOD_ADD(P,N)

N 月を期間 P (型 YYMM または YYYYMM) に追加します。YYYYMM を返します。注意: 期間引数 P は日付値では ありません。

mysql> SELECT PERIOD_ADD(9801,2);
        -> 199803

PERIOD_DIFF(P1,P2)

期間 P1 と P2 の差の月を返します。P1 と P2 は形式 YYMM または YYYYMM です。注意: 期間引数 P1 と P2 は日付値では ありません。

mysql> SELECT PERIOD_DIFF(9802,199703);
        -> 11

DATE_ADD(date,INTERVAL expr type)

DATE_SUB(date,INTERVAL expr type)

ADDDATE(date,INTERVAL expr type)

SUBDATE(date,INTERVAL expr type)

これら関数は日付の演算に使用します。これらは MySQL バージョン 3.22 の新しい機能です。 ADDDATE() と SUBDATE() は DATE_ADD() , DATE_SUB() と同義です。 MySQL バージョン 3.23 では, + と - を DATE_ADD() , DATE_SUB() の代わりに使用できます. (See example below.) date には、DATETIME か DATE 型の値を指定します。この値から演算が開始されます。 expr には、date から増減させる値を指定します。 expr が `-' から始まっていれば、負数を示します。 type はどれぐらいの期間かを示すキーワードです。 EXTRACT(type FROM date) 関数は、date から 'type' の部分を返します。以下の表に、type と expr の関連を示します：

`type` value	Expected `expr` format
`SECOND`	`SECONDS`
`MINUTE`	`MINUTES`
`HOUR`	`HOURS`
`DAY`	`DAYS`
`MONTH`	`MONTHS`
`YEAR`	`YEARS`
`MINUTE_SECOND`	`"MINUTES:SECONDS"`
`HOUR_MINUTE`	`"HOURS:MINUTES"`
`DAY_HOUR`	`"DAYS HOURS"`
`YEAR_MONTH`	`"YEARS-MONTHS"`
`HOUR_SECOND`	`"HOURS:MINUTES:SECONDS"`
`DAY_MINUTE`	`"DAYS HOURS:MINUTES"`
`DAY_SECOND`	`"DAYS HOURS:MINUTES:SECONDS"`

MySQL は、 expr フォーマット内のいかなる句読点区切りをも許します。上の表中の区切り文字は提案する区切り文字です。もし date 引数が DATE 値で、YEAR, MONTH, DAY の部分のみを含む計算をするなら、結果は DATE 値が返ります。それ以外なら DATETIME 値が返ります:

mysql> SELECT "1997-12-31 23:59:59" + INTERVAL 1 SECOND;
        -> 1998-01-01 00:00:00
mysql> SELECT INTERVAL 1 DAY + "1997-12-31";
        -> 1998-01-01
mysql> SELECT "1998-01-01" - INTERVAL 1 SECOND;
       -> 1997-12-31 23:59:59
mysql> SELECT DATE_ADD("1997-12-31 23:59:59",
    ->                 INTERVAL 1 SECOND);
        -> 1998-01-01 00:00:00
mysql> SELECT DATE_ADD("1997-12-31 23:59:59",
    ->                 INTERVAL 1 DAY);
        -> 1998-01-01 23:59:59
mysql> SELECT DATE_ADD("1997-12-31 23:59:59",
    ->                 INTERVAL "1:1" MINUTE_SECOND);
        -> 1998-01-01 00:01:00
mysql> SELECT DATE_SUB("1998-01-01 00:00:00",
    ->                 INTERVAL "1 1:1:1" DAY_SECOND);
        -> 1997-12-30 22:58:59
mysql> SELECT DATE_ADD("1998-01-01 00:00:00",
    ->                 INTERVAL "-1 10" DAY_HOUR);
        -> 1997-12-30 14:00:00
mysql> SELECT DATE_SUB("1998-01-02", INTERVAL 31 DAY);
        -> 1997-12-02

もしあなたの指定する interval 値が短すぎるなら( type キーワードから類推される値を含んでいない場合)、 MySQL は interval 値の一番左の部分を指定し忘れたものだと仮定します。例えば、もし type を DAY_SECOND に指定した場合、 expr の値は日、時、分、秒からなる物と期待されます。ここであなたが "1:10" のような値を指定していたなら、 MySQL は、日、時の部分が忘れ去られて、分、秒が与えられたと推定します。つまり、 "1:10" DAY_SECOND は "1:10" MINUTE_SECOND であると理解されるのです。これは、MySQL が TIME 値を時刻ではなく経過時間の表現と解釈する方法に類似しています。注意: 時刻部を含む何かに対して、日付値の加算や減算を行なう場合、日付値は自動的に日時値に変換されます:

mysql> SELECT DATE_ADD("1999-01-01", INTERVAL 1 DAY);
       -> 1999-01-02
mysql> SELECT DATE_ADD("1999-01-01", INTERVAL 1 HOUR);
       -> 1999-01-01 01:00:00

もし、不正な値が使用されたなら、結果は NULL です. もし MONTH や YEAR_MONTH や YEAR を足し算して、結果となる日付が新しい月の最大日よりも大きい日になるようなら、その日は、新しい月の最大日に修正されます。

mysql> SELECT DATE_ADD('1998-01-30', Interval 1 month);
        -> 1998-02-28

例のように、INTERVAL と type キーワードはケース依存ではありません.

EXTRACT(type FROM date)

The EXTRACT() function uses the same kinds of interval type specifiers as DATE_ADD() or DATE_SUB(), but extracts parts from the date rather than performing date arithmetic.

mysql> SELECT EXTRACT(YEAR FROM "1999-07-02");
       -> 1999
mysql> SELECT EXTRACT(YEAR_MONTH FROM "1999-07-02 01:02:03");
       -> 199907
mysql> SELECT EXTRACT(DAY_MINUTE FROM "1999-07-02 01:02:03");
       -> 20102

TO_DAYS(date)

日付 date を与えると、0年からの日数を返します。

mysql> SELECT TO_DAYS(950501);
        -> 728779
mysql> SELECT TO_DAYS('1997-10-07');
        -> 729669

TO_DAYS() はグレゴリオ歴の開始(1582)より前の値での使用を意図されていません。歴が変更された時に失われた日を考慮に入れてないからです。

FROM_DAYS(N)

与えられた日数 N から DATE 値を返します:

mysql> SELECT FROM_DAYS(729669);
        -> '1997-10-07'

FROM_DAYS() はグレゴリオ歴の開始(1582)より前の値での使用を意図されていません。歴が変更された時に失われた日を考慮に入れてないからです。

DATE_FORMAT(date,format)

date 値を format 文字列に従って整形します。次の指定が format 文字列で使用できます:

Specifier	Description
`%M`	月名 (`January`..`December`)
`%W`	曜日 (`Sunday`..`Saturday`)
`%D`	英語サフィックス付き月の日 (`0th`, `1st`, `2nd`, `3rd`, etc.)
`%Y`	4桁の年
`%y`	2桁の年
`%X`	週の年。週の最初の日は日曜日。4桁の数値。'%V' と共に使用されます
`%x`	週の年。週の最初の日は月曜日。4桁の数値。'%v' と共に使用されます
`%a`	省略された曜日名 (`Sun`..`Sat`)
`%d`	月の日, 数値 (`00`..`31`)
`%e`	月の日, 数値 (`0`..`31`)
`%m`	月, 数値 (`00`..`12`)
`%c`	月, 数値 (`0`..`12`)
`%b`	省略された月名 (`Jan`..`Dec`)
`%j`	年の日 (`001`..`366`)
`%H`	時 (`00`..`23`)
`%k`	時 (`0`..`23`)
`%h`	時 (`01`..`12`)
`%I`	時 (`01`..`12`)
`%l`	時 (`1`..`12`)
`%i`	分, 数値 (`00`..`59`)
`%r`	時刻, 12時間 (`hh:mm:ss [AP]M`)
`%T`	時刻, 24時間 (`hh:mm:ss`)
`%S`	秒 (`00`..`59`)
`%s`	秒 (`00`..`59`)
`%p`	`AM` or `PM`
`%w`	週の日 (`0`=Sunday..`6`=Saturday)
`%U`	週 (`00`..`53`), 週のはじまりを日曜とした場合
`%u`	週 (`00`..`53`), 週のはじまりを月曜とした場合
`%V`	週 (`01`..`53`), 週のはじまりは日曜日。'%X' と共に使用されます
`%v`	週 (`01`..`53`), 週のはじまりは月曜日。'%x' と共に使用されます
`%%`	リテラル `%'。

他の全ての文字は解釈されずに結果にコピーされます:

mysql> SELECT DATE_FORMAT('1997-10-04 22:23:00', '%W %M %Y');
        -> 'Saturday October 1997'
mysql> SELECT DATE_FORMAT('1997-10-04 22:23:00', '%H:%i:%s');
        -> '22:23:00'
mysql> SELECT DATE_FORMAT('1997-10-04 22:23:00',
                          '%D %y %a %d %m %b %j');
        -> '4th 97 Sat 04 10 Oct 277'
mysql> SELECT DATE_FORMAT('1997-10-04 22:23:00',
                          '%H %k %I %r %T %S %w');
        -> '22 22 10 10:23:00 PM 22:23:00 00 6'
mysql> SELECT DATE_FORMAT('1999-01-01', '%X %V');
        -> '1998 52'

MySQL バージョン 3.23 では、 % 文字はフォーマット文字の前に必ず必要とされます。それより前のバージョンでは、 % 文字はオプションでした。 The reason the ranges for the month and day specifiers begin with zero is that MySQL allows incomplete dates such as '2004-00-00' to be stored as of MySQL 3.23.

TIME_FORMAT(time,format)

これは上記の DATE_FORMAT() のように使用されますが、 format オプションでは、時,分,秒だけを操作できます。他のオプションは NULL or 0 を与えます。

CURDATE()

CURRENT_DATE

今日の日付を返します。日付の形式は、CURDATE() が数値または文字列のどちらの文脈で使用されたかに依存して YYYYMMDD または 'YYYY-MM-DD' で返されます:

mysql> SELECT CURDATE();
        -> '1997-12-15'
mysql> SELECT CURDATE() + 0;
        -> 19971215

CURTIME()

CURRENT_TIME

現在の時刻を HHMMSS または 'HH:MM:SS' の形式で返します。これは CURTIME() が数値または文字列のどちらの文脈で使用されたかに依存します:

mysql> SELECT CURTIME();
        -> '23:50:26'
mysql> SELECT CURTIME() + 0;
        -> 235026

NOW()

SYSDATE()

CURRENT_TIMESTAMP

現在の時刻を返します。数値または文字列のどちらの文脈で使用されたかに依存して YYYYMMDDHHMMSS または 'YYYY-MM-DD HH:MM:SS' 形式で返されます:

mysql> SELECT NOW();
        -> '1997-12-15 23:50:26'
mysql> SELECT NOW() + 0;
        -> 19971215235026

Note that NOW() is only evaluated once per query, namely at the start of query execution. This means that multiple references to NOW() within a single query will always give the same time.

UNIX_TIMESTAMP()

UNIX_TIMESTAMP(date)

引数なしで呼び出された場合は、UNIX timestamp (GMT '1970-01-01 00:00:00' からの秒数) です。If UNIX_TIMESTAMP() is called with a date argument, it returns the value of the argument as seconds since

'1970-01-01
00:00:00'

GMT. date はローカル時刻での DATE 文字列、DATETIME 文字列、TIMESTAMP, または YYMMDD または YYYYMMDD 形式の数値です:

mysql> SELECT UNIX_TIMESTAMP();
        -> 882226357
mysql> SELECT UNIX_TIMESTAMP('1997-10-04 22:23:00');
        -> 875996580

UNIX_TIMESTAMP が TIMESTAMP フィールドに使用された場合、この関数は、暗黙の ``文字から UNIX タイムスタンプ'' 変換をすることなく、値を得ます。 If you pass an out-of-range date to UNIX_TIMESTAMP() it will return 0, but please note that only basic checking is performed (year 1970-2037, month 01-12, day 01-31). If you want to subtract UNIX_TIMESTAMP() columns, you may want to cast the result to signed integers. 「6.3.5 Cast Functions」節参照.

FROM_UNIXTIME(unix_timestamp)

文脈(数値/文字列)に依存して、'YYYY-MM-DD HH:MM:SS' または YYYYMMDDHHMMSS 形式の timestamp 文字列を返します:

mysql> SELECT FROM_UNIXTIME(875996580);
        -> '1997-10-04 22:23:00'
mysql> SELECT FROM_UNIXTIME(875996580) + 0;
        -> 19971004222300

FROM_UNIXTIME(unix_timestamp,format)

format に従って整形された UNIX timestamp 文字列を返します。 format は DATE_FORMAT() 関数のエントリに一覧されたのと同じ指定子を含むことができます:

mysql> SELECT FROM_UNIXTIME(UNIX_TIMESTAMP(),
                            '%Y %D %M %h:%i:%s %x');
        -> '1997 23rd December 03:43:30 1997'

SEC_TO_TIME(seconds)

seconds 引数を時分秒に変換して返します。関数が文字列文脈または数値文脈のどちらで使用されたかに依存して、'HH:MM:SS' または HHMMSS 形式で値を返します:

mysql> SELECT SEC_TO_TIME(2378);
        -> '00:39:38'
mysql> SELECT SEC_TO_TIME(2378) + 0;
        -> 3938

TIME_TO_SEC(time)

time を秒に変換します。

mysql> SELECT TIME_TO_SEC('22:23:00');
        -> 80580
mysql> SELECT TIME_TO_SEC('00:39:38');
        -> 2378

6.3.5 Cast Functions

The syntax of the CAST function is:

CAST(expression AS type)

or

CONVERT(expression,type)

Where type is one of:

BINARY
CHAR (New in 4.0.6)
DATE
DATETIME
SIGNED {INTEGER}
TIME
UNSIGNED {INTEGER}

CAST() is ANSI SQL99 syntax and CONVERT() is ODBC syntax.

The cast function is mainly useful when you want to create a column with a specific type in a CREATE ... SELECT:

CREATE TABLE new_table SELECT CAST('2000-01-01' AS DATE);

CAST(string AS BINARY is the same thing as BINARY string. CAST(expr AS CHAR threats expression to be a string with the default character set.

To cast a string to a numeric value, you don't normally have to do anything; just use the string value as it would be a number:

mysql> SELECT 1+'1';
       -> 2

If you use a number in string context the number will automatically be converted to a BINARY string.

mysql> SELECT CONCAT("hello you ",2);
       ->  "hello you 2"

MySQL supports arithmetic with both signed and unsigned 64-bit values. If you are using an numerical operations (like +) and one of the operands are unsigned integer, then the result will be unsigned. You can override this by using the SIGNED and UNSIGNED cast operators, which will cast the operation to a signed or unsigned 64-bit integer, respectively.

mysql> SELECT CAST(1-2 AS UNSIGNED)
        -> 18446744073709551615
mysql> SELECT CAST(CAST(1-2 AS UNSIGNED) AS SIGNED);
        -> -1

Note that if either operation is a floating-point value (In this context DECIMAL() is regarded as a floating-point value) the result will be a floating-point value and is not affected by the above rule.

mysql> SELECT CAST(1 AS UNSIGNED) -2.0
        -> -1.0

If you are using a string in an arithmetic operation, this is converted to a floating-point number.

The CAST() and CONVERT() functions were added in MySQL 4.0.2.

The handing of unsigned values was changed in MySQL 4.0 to be able to support BIGINT values properly. If you have some code that you want to run in both MySQL 4.0 and 3.23 (in which case you probably can't use the CAST function), you can use the following trick to get a signed result when subtracting two unsigned integer columns:

SELECT (unsigned_column_1+0.0)-(unsigned_column_2+0.0);

The idea is that the columns are converted to floating-point before doing the subtraction.

If you get a problem with UNSIGNED columns in your old MySQL application when porting to MySQL 4.0, you can use the --sql-mode=NO_UNSIGNED_SUBTRACTION option when starting mysqld. Note however that as long as you use this, you will not be able to make efficient use of the UNSIGNED BIGINT column type.

6.3.6 その他の関数

6.3.6.1 ビット関数

これらは最大 64 ビットの範囲を持ちます。MySQL は BIGINT (64-bit) 演算を使用するためです。

|

ビット演算 OR

mysql> SELECT 29 | 15;
        -> 31

The result is an unsigned 64-bit integer.

&

ビット演算 AND

mysql> SELECT 29 & 15;
        -> 13

The result is an unsigned 64-bit integer.

^

Bitwise XOR

mysql> SELECT 1 ^ 1;
        -> 0
mysql> SELECT 1 ^ 0;
        -> 1
mysql> SELECT 11 ^ 3;
        -> 8

The result is an unsigned 64-bit integer. XOR was added in version 4.0.2.

<<

左に longlong (BIGINT) number 分、ビットをシフトします:

mysql> SELECT 1 << 2;
        -> 4

The result is an unsigned 64-bit integer.

>>

右に longlong (BIGINT) number 分、ビットをシフトします:

mysql> SELECT 4 >> 2;
        -> 1

The result is an unsigned 64-bit integer.

~

Invert all bits:

mysql> SELECT 5 & ~1;
        -> 4

The result is an unsigned 64-bit integer.

BIT_COUNT(N)

引数 N がいくつビットを持っているか(２進数表記したときの１の数):

mysql> SELECT BIT_COUNT(29);
        -> 4

6.3.6.2 その他の関数

DATABASE()

現在のデータベース名を返します

mysql> SELECT DATABASE();
        -> 'test'

もしデータベースが選択されていないなら、DATABASE() は空文字を返します。

USER()

SYSTEM_USER()

SESSION_USER()

Returns the current MySQL user name:

mysql> SELECT USER();
        -> 'davida@localhost'

MySQL バージョン 3.22.11 以降では、この関数はユーザー名とクライアントのホスト名を含みます。ユーザー名の部分だけ取り出すには次のようにします。（これはホスト名が含まれていなくとも動くでしょう）：

mysql> SELECT substring_index(USER(),"@",1);
        -> 'davida'

CURRENT_USER()

Returns the user name, current session was authentificated as:

mysql> SELECT USER();
        -> 'davida@localhost'
mysql> SELECT * FROM mysql.user;
        -> ERROR 1044: Access denied for user: '@localhost' to database 'mysql'
mysql> SELECT CURRENT_USER();
        -> '@localhost'

PASSWORD(str)

OLD_PASSWORD(str)

プレーンテキストのパスワード str からパスワード文字列を計算します。これは user 許可テーブルの Password フィールドに、暗号化された MySQL パスワードを保存する際に使用されます:

mysql> SELECT PASSWORD('badpwd');
        -> '7f84554057dd964b'

PASSWORD() 暗号は不可逆です。 PASSWORD() は UNIX のパスワードが暗号化するのと同じ方法で暗号化を行うわけではありません。 ENCRYPT() 参照。 注意: PASSWORD() 関数は MySQL サーバー内の認証システムで使用されます。その関数をあなたの独自アプリケーションでは使用すべきではありません。そうしたければ、代わりに MD5() や SHA1() を使用します。 Also see RFC-2195 for more information about handling passwords and authentication securely in your application.

ENCRYPT(str[,salt])

UNIX の crypt() システムコールで str を暗号化します。 salt は2文字の文字列です。 (MySQL バージョン 3.22.16 で, salt は2文字以上許されるようになりました。)

mysql> SELECT ENCRYPT("hello");
        -> 'VxuFAJXVARROc'

システムで crypt() が利用できない場合は ENCRYPT() は常に NULL を返します。少なくともいくつかのシステムでは、 ENCRYPT() は str 文字中の最初の 8 文字以外は全て無視します。これは crypt() システムコールの振る舞いによって決定づけられます。

ENCODE(str,pass_str)

パスワードとして pass_str を用いて str を暗号化します。結果を復号化するには、DECODE()を使用します。結果はバイナリ文字列で、長さは string と同じです。フィールドにそれを保存したい場合は BLOB フィールド型を使用してください。

DECODE(crypt_str,pass_str)

暗号化された文字列 crypt_str をパスワードとして pass_str を用いて復号化します。crypt_str は ENCODE() から返された文字列であるべきです。

MD5(string)

文字列を MD5 128bit チェックサムした結果を返します。値は 32 桁の 16進表示です。例えばハッシュキーとして使用できるように:

mysql> SELECT MD5("testing");
        -> 'ae2b1fca515949e5d54fb22b8ed95575'

これは "RSA Data Security, Inc. MD5 Message-Digest Algorithm".

SHA1(string)

SHA(string)

Calculates an SHA1 160 bit checksum for the string, as described in RFC 3174 (Secure Hash Algorithm). The value is returned as a 40 digit hex number, or NULL in case the input argument was NULL. One of the possible uses for this function is as a hash key. You can also use it as cryptographically safe function for storing passwords.

mysql> SELECT SHA1("abc");
        -> 'a9993e364706816aba3e25717850c26c9cd0d89d'

SHA1() was added in version 4.0.2, and can be considered a cryptographically more secure equivalent of MD5(). SHA() is synonym for SHA1().

AES_ENCRYPT(string,key_string)

AES_DECRYPT(string,key_string)

These functions allow encryption/decryption of data using the official AES (Advanced Encryption Standard) algorithm, previously known as Rijndael. Encoding with 128 bit key length is used, but you can extend it up to 256 bit by patching the source. We chose 128 bits because it is much faster and it is usually secure enough. The input arguments may be any length. If either argument is NULL, the result of this function is also NULL. As AES is a block level algorithm, padding is used to encode uneven length strings and so the result string length may be calculated as 16*(trunc(string_length/16)+1). If AES_DECRYPT() detects invalid data or incorrect padding, it will return NULL. However, it is possible for AES_DECRYPT() to return a non-NULL value (possibly garbage) if the input data or the key was invalid. You can use the AES functions to store data in an encrypted form by modifying your queries:

INSERT INTO t VALUES (1,AES_ENCRYPT("text","password"));

You can get even more security by avoiding transferring the key over the connection for each query, which can be accomplished by storing it in a server side variable at connection time:

SELECT @password:="my password";
INSERT INTO t VALUES (1,AES_ENCRYPT("text",@password));

AES_ENCRYPT() and AES_DECRYPT() were added in version 4.0.2, and can be considered the most cryptographically secure encryption functions currently available in MySQL.

DES_ENCRYPT(string_to_encrypt [, (key_number | key_string) ] )

Encrypts the string with the given key using the Triple-DES algorithm. Note that this function only works if you have configured MySQL with SSL support. 「4.3.9 Using Secure Connections」節参照. The encryption key to use is chosen the following way:

Argument	Description
Only one argument	The first key from `des-key-file` is used.
key number	The given key (0-9) from the `des-key-file` is used.
string	The given `key_string` will be used to crypt `string_to_encrypt`.

The return string will be a binary string where the first character will be CHAR(128 | key_number). The 128 is added to make it easier to recognise an encrypted key. If you use a string key, key_number will be 127. On error, this function returns NULL. The string length for the result will be new_length= org_length + (8-(org_length % 8))+1. The des-key-file has the following format:

key_number des_key_string
key_number des_key_string

Each key_number must be a number in the range from 0 to 9. Lines in the file may be in any order. des_key_string is the string that will be used to encrypt the message. Between the number and the key there should be at least one space. The first key is the default key that will be used if you don't specify any key argument to DES_ENCRYPT() You can tell MySQL to read new key values from the key file with the FLUSH DES_KEY_FILE command. This requires the Reload_priv privilege. One benefit of having a set of default keys is that it gives applications a way to check for existence of encrypted column values, without giving the end user the right to decrypt those values.

mysql> SELECT customer_address FROM customer_table WHERE
       crypted_credit_card = DES_ENCRYPT("credit_card_number");

DES_DECRYPT(string_to_decrypt [, key_string])

Decrypts a string encrypted with DES_ENCRYPT(). Note that this function only works if you have configured MySQL with SSL support. 「4.3.9 Using Secure Connections」節参照. If no key_string argument is given, DES_DECRYPT() examines the first byte of the encrypted string to determine the DES key number that was used to encrypt the original string, then reads the key from the des-key-file to decrypt the message. For this to work the user must have the SUPER privilege. If you pass this function a key_string argument, that string is used as the key for decrypting the message. If the string_to_decrypt doesn't look like an encrypted string, MySQL will return the given string_to_decrypt. On error, this function returns NULL.

LAST_INSERT_ID([expr])

最後に AUTO_INCREMENT フィールドに挿入されて自動的に生成された値を返します。「8.4.3.130 mysql_insert_id()」節参照.

mysql> SELECT LAST_INSERT_ID();
        -> 195

最後の作成された ID はそれぞれのコネクション毎にサーバーに維持されます。これは他のクライアントからは変更できないでしょう。もし他の非マジック値をもつ AUTO_INCREMENT フィールド（値が NULL でも 0 でもないということ）を更新しても、これは変更されません。一つの INSERT 文で同時に多くのレコードを挿入する場合、 LAST_INSERT_ID() は最初に挿入されたレコードの値を返します。この理由は、他のサーバに対して同じ INSERT を簡単に再現できるようにするためです。 If expr is given as an argument to LAST_INSERT_ID(), then the value of the argument is returned by the function, is set as the next value to be returned by LAST_INSERT_ID() and used as the next auto_increment value. これはシーケンス番号のシミュレーションに使用できます：最初にテーブルを作成：

mysql> CREATE TABLE sequence (id int not null);
mysql> INSERT INTO sequence VALUES (0);

そして以下のようにしてシーケンス番号を生成：

mysql> UPDATE sequence SET id=LAST_INSERT_ID(id+1);

LAST_INSERT_ID() の呼び出し無しでシーケンス番号を生成することが可能ですが、この方法でこの関数を使用するユーティリティは、ID 値が最後に自動的に生成された値としてサーバに管理されます。MySQL 内の通常の任意の AUTO_INCREMENT 値を読み込んで新しい ID を取り出すことができます。例えば、LAST_INSERT_ID() (引数無し) は新しい ID を返します。C API 関数 mysql_insert_id() もこの値を得るために使用できます。 Note that as mysql_insert_id() is only updated after INSERT and UPDATE statements, so you can't use the C API function to retrieve the value for LAST_INSERT_ID(expr) after executing other SQL statements like SELECT or SET.

FORMAT(X,D)

'#,###,###.##' のような形式(小数部 X 桁)で数値 D を整形します。もし D が 0 なら, 結果にはいかなる小数点も小数部も含まれません。

mysql> SELECT FORMAT(12332.123456, 4);
        -> '12,332.1235'
mysql> SELECT FORMAT(12332.1,4);
        -> '12,332.1000'
mysql> SELECT FORMAT(12332.2,0);
        -> '12,332'

VERSION()

MySQL サーバのバージョンを返します:

mysql> SELECT VERSION();
        -> '3.23.13-log'

注意: バージョンが -log で終わる場合はロギングが有効であることを意味します。

CONNECTION_ID()

接続の接続 ID (thread_id) を返します。すべての接続は接続自身の一意な ID を持ちます:

mysql> SELECT CONNECTION_ID();
        -> 1

GET_LOCK(str,timeout)

timeout 秒のタイムアウトで、str と名付けられたロックの獲得を試みます。ロックを獲得した場合は 1, タイムアウトの場合は 0, エラーの場合(メモリ不足やスレッドが mysqladmin kill で殺された場合など)は NULL が返ります。RELEASE_LOCK の実行、新しい GET_LOCK の実行、スレッドの終了の場合に、ロックは解放されます。この関数はアプリケーションロックやレコードロックのシミュレートのために使用できます。これは、同じ名前のロックを行おうとする他のクライアントからのリクエストをブロックします；与えられた名前のロックに応じているクライアントは、協調してロッキングを行うために、その文字列を使用できます:

mysql> SELECT GET_LOCK("lock1",10);
        -> 1
mysql> SELECT IS_FREE_LOCK("lock2");
        -> 1
mysql> SELECT GET_LOCK("lock2",10);
        -> 1
mysql> SELECT RELEASE_LOCK("lock2");
        -> 1
mysql> SELECT RELEASE_LOCK("lock1");
        -> NULL

２つ目の RELEASE_LOCK() は NULL を返します。なぜなら、 "lock1" は、２つ目の GET_LOCK() の呼び出し時点で、自動的に解放されるからです。

RELEASE_LOCK(str)

GET_LOCK で獲得したロック str を解放します。ロックが解放された場合は 1, このスレッドによってロックされていない場合は 0 (この場合、ロックは解放されません), strが存在しない場合は NULL が返ります。もし、 GET_LOCK() をコールして得られなかった場合、あるいは、既に解放されている場合は、ロックは存在しないでしょう。 The DO statement is convinient to use with RELEASE_LOCK(). 「6.4.10 DO Syntax」節参照.

IS_FREE_LOCK(str)

Checks if the lock named str is free to use (i.e., not locked). Returns 1 if the lock is free (no one is using the lock), 0 if the lock is in use, and NULL on errors (like incorrect arguments).

BENCHMARK(count,expr)

BENCHMARK() 関数は expr で与えられた文を count 回繰り返し実行します。これは MySQL のその文の処理がどれぐらい速いのか知るのに使用されるでしょう。結果は常に 0 です。想定している使用は、 mysql クライアントです。あるクエリの実行時間を知るための使用です:

mysql> SELECT BENCHMARK(1000000,ENCODE("hello","goodbye"));
+----------------------------------------------+
| BENCHMARK(1000000,ENCODE("hello","goodbye")) |
+----------------------------------------------+
|                                            0 |
+----------------------------------------------+
1 row in set (4.74 sec)

報告された時間は、クライアントでの経過時間です。サーバー側の CPU 時間ではありません。BENCHMARK() を何回か実行して、サーバマシンの負荷の重さを考慮して結果を解釈することを勧めます。

INET_NTOA(expr)

数値表現に対するネットワークアドレス(4 または 8 バイト) を返します:

mysql> SELECT INET_NTOA(3520061480);
       ->  "209.207.224.40"

INET_ATON(expr)

ネットワークアドレスに対する数値を表す整数を返します。アドレスは 4 または 8 バイトアドレスです:

mysql> SELECT INET_ATON("209.207.224.40");
       ->  3520061480

生成された数値は常にネットワークバイトオーダです; たとえば、上記の数値は 209*255^3 + 207*255^2 + 224*255 +40 として計算されます。

MASTER_POS_WAIT(log_name, log_pos)

マスターログの指定された位置にスレーブが到達するまで(すなわち、スレーブが読み込んで全て更新しおわるまで)ブロックします。マスター情報が初期化されていないか引数が違う場合、NULL が返ります。スレーブが動作していない場合、ブロックし、スレーブが起動し、指定位置にくるまで待ちます。スレーブが既に指定位置を通り過ぎていた場合、即時復帰します。 If timeout (new in 4.0.10) is specified, will give up waiting when timeout seconds have elapsed. timeout must be greater than 0; a zero or negative timeout means no timeout. The return value is the number of log events it had to wait to get to the specified position, or NULL in case of error, or -1 if the timeout has been exceeded. This command is useful for control of master-slave synchronisation, but was originally written to facilitate replication testing.

FOUND_ROWS()

Returns the number of rows that the last SELECT SQL_CALC_FOUND_ROWS ... command would have returned, if it had not been restricted with LIMIT.

mysql> SELECT SQL_CALC_FOUND_ROWS * FROM tbl_name
       WHERE id > 100 LIMIT 10;
mysql> SELECT FOUND_ROWS();

The second SELECT will return a number indicating how many rows the first SELECT would have returned had it been written without the LIMIT clause. Note that if you are using SELECT SQL_CALC_FOUND_ROWS ... MySQL has to calculate all rows in the result set. However, this is faster than if you would not use LIMIT, as the result set need not be sent to the client. SQL_CALC_FOUND_ROWS is available starting at MySQL version 4.0.0.

6.3.6.3 Functions for Use with `GROUP BY` Clauses

GROUP BY節を含まない文でグループ関数を使用すると全てのレコードについてグループされたものとみなされます。

COUNT(expr)

Returns a count of the number of non-NULL values in the rows retrieved by a SELECT statement: SELECT文により選択されたレコードからNULLではないものの数を返します。

mysql> SELECT student.student_name,COUNT(*)
           FROM student,course
           WHERE student.student_id=course.student_id
           GROUP BY student_name;

COUNT(*)はNULLを含むかどうかで選択されたレコードの数を返すだけです。 COUNT(*)は一つのテーブルから一つだけカラムが選択され、尚且つWHERE節が使用されていない場合に最適化され、高速に動作します。例えば以下のように使います。

mysql> SELECT COUNT(*) FROM student;

COUNT(DISTINCT expr,[expr...])

これはNULL値では無い値を持つデータの数を区別して返すことが出来ます。

mysql> SELECT COUNT(DISTINCT results) from student;

複数の選択されたデータ群からNULLを含まないデータの総数算出が必要な場合、 MySQLでは必要な選択リストを与えることによって得ることが出来ます。一方でANSIのSQLではその選択一つ一つについて COUNT(DISTINCT ...) を使う必要があります。

AVG(expr)

exprで得られる値の平均値を返します。

mysql> SELECT student_name, AVG(test_score)
           FROM student
           GROUP BY student_name;

MIN(expr)

MAX(expr)

exprで得られる値の最大値、最小値を返します。 MIN()とMAX()の引数は文字列を取ることもできます。この際は文字列の値の大小を比較し、最大と最小を返します。「5.4.3 MySQL はどのようにインデックスを使用するか？」節.

mysql> SELECT student_name, MIN(test_score), MAX(test_score)
    ->        FROM student
    ->        GROUP BY student_name;

In MIN(), MAX() and other aggregate functions, MySQL currently compares ENUM and SET columns by their string value rather than by the string's relative position in the set. This will be rectified.

SUM(expr)

exprで得られる値の総計を返します。もしも得られるレコードが見つからない場合はNULLが返ってきます。

VARIANCE(expr)

Returns the standard variance of expr. This is an extension to ANSI SQL (available only in version 4.1 or later).

STD(expr)

STDDEV(expr)

exprで得られる値の標準偏差を返します。これはANSI SQLの格調になっています。関数としてのSTDDEV()の形はOracleのものと互換性があります。

BIT_OR(expr)

exprで得られる値のビット和(OR)を返します。計算は64-bit(BIGINT)の精度で行われます。

BIT_AND(expr)

exprで得られる値のビット積(AND)を返します。計算は64-bit(BIGINT)の精度で行われます。

MySQLのGROUP BYは拡張された使い方が可能です。 SELECTで使用したフィールド名や計算式をGROUP BYには使用しない、という使い方が可能です。このことはグループにはどんな値も使用可能ということを表しています。データの並べ替えやグループ分けに適さない要素を排除することによってより良好なパフォーマンスを得ることが出来ます。例えば、次のようなクエリでcustomer.nameについてのグループ分けをする必要はありません。

mysql> SELECT order.custid,customer.name,MAX(payments)
    ->        FROM order,customer
    ->        WHERE order.custid = customer.custid
    ->        GROUP BY order.custid;

ANSI SQLではcustomer.nameをGROUP BYのところに追加する必要があります。 MySQLではANSIモードで動かしていない限り余計な記述の必要はありません。

GROUP BYで省略するフィールドはグループ内でユニークでなくてはいけません。もしそうでない場合は結果は予想もしないようなものになるでしょう。

たとえユニークでは無くても特定のフィールドの値を得るために MIN()やMAX()を使用できるケースもあります。次の例はsortフィールド中の最小値を持つレコードから特定のcolumnの値を取り出します。

SUBSTR(MIN(CONCAT(RPAD(sort,6,' '),column)),7)

「3.5.4 The Rows Holding the Group-wise Maximum of a Certain Field」節参照.

MySQLの3.22以前のバージョンをお使いであるか、ANSI SQLに沿っての使用をされる場合は GROUP BYとORDER BY内に選択表現を記述してはいけません。この制限を守った上で作業を進めるにはエイリアスを使用します。

mysql> SELECT id,FLOOR(value/100) AS val FROM tbl_name
    ->        GROUP BY id,val ORDER BY val;

MySQLのバージョン3.23では次のようにも記述できます。

mysql> SELECT id,FLOOR(value/100) FROM tbl_name ORDER BY RAND();

6.4 Data Manipulation: `SELECT`, `INSERT`, `UPDATE`, `DELETE`

6.4.1 `SELECT` 構文

SELECT [STRAIGHT_JOIN]
       [SQL_SMALL_RESULT] [SQL_BIG_RESULT] [SQL_BUFFER_RESULT]
       [SQL_CACHE | SQL_NO_CACHE] [SQL_CALC_FOUND_ROWS] [HIGH_PRIORITY]
       [DISTINCT | DISTINCTROW | ALL]
    select_expression,...
    [INTO {OUTFILE | DUMPFILE} 'file_name' export_options]
    [FROM table_references
      [WHERE where_definition]
      [GROUP BY {unsigned_integer | col_name | formula} [ASC | DESC], ...]
      [HAVING where_definition]
      [ORDER BY {unsigned_integer | col_name | formula} [ASC | DESC] ,...]
      [LIMIT [offset,] rows | rows OFFSET offset]
      [PROCEDURE procedure_name(argument_list)]
      [FOR UPDATE | LOCK IN SHARE MODE]]

SELECTは通常、1つまたは1つ以上のテーブルからレコードを検索して抽出するのに使用されます。 select_expression は取り出したいフィールドを示します。 SELECTはまた、テーブルの参照なしに計算によって求められたレコードを取り出すために使用されます。例:

mysql> SELECT 1 + 1;
         -> 2

全てのキーワードの使用は、上記に示すような順序で正確に与えられる必要があります。例えば、HAVING節は必ずGROUP BY節の後、ORDER BY節の前でなければなりません。

SELECTの表現では、ASによる別名の指定が可能です。別名は、フィールド名の表現として使われ、ORDER BY及びHAVING節とともに使用することができます。例:
```
mysql> SELECT CONCAT(last_name,', ',first_name) AS full_name
    FROM mytable ORDER BY full_name;
```
It is not allowed to use a column alias in a WHERE clause, because the column value may not yet be determined when the WHERE clause is executed. 「A.5.4 alias の問題」節参照.
FROM table_references節は、(例えば、選択するレコードにより、1つ又はそれ以上の) 結合するテーブルのリストを示します。このリストはまた、LEFT OUTER JOIN参照を含むことがあります。「6.4.1.1 JOIN 構文」節. を参照してください。 For each table specified, you may optionally specify an alias.
```
table_name [[AS] alias] [[USE INDEX (key_list)] | [IGNORE INDEX (key_list)] | FORCE INDEX (key_list)]]
```
As of MySQL Version 3.23.12, you can give hints about which index MySQL should use when retrieving information from a table. This is useful if EXPLAIN shows that MySQL is using the wrong index from the list of possible indexes. By specifying USE INDEX (key_list), you can tell MySQL to use only one of the possible indexes to find rows in the table. The alternative syntax IGNORE INDEX (key_list) can be used to tell MySQL to not use some particular index. In MySQL 4.0.9 you can also use FORCE INDEX. This acts likes USE INDEX (key_list) but with the addition that a table scan is assumed to be VERY expensive. In other words a table scan will only be used if there is no way to use one of the given index to find rows in the table. USE/IGNORE/FORCE KEY are synonyms for USE/IGNORE/FORCE INDEX.
You can refer to a table as tbl_name (within the current database), or as dbname.tbl_name to explicitly specify a database. col_name、tbl_name.col_name、db_name.tbl_name.col_nameのようにしてフィールドを表すことができます。 SELECTステートメント内での列の参照が曖昧でなければ、tbl_nameや db_name.tbl_nameのようなプリフィックスを詳細に記述する必要はありません。より明示的なフィールドの指定形式をを必要とする曖昧な参照の例は、「6.1.2 データベース名、テーブル名、インデックス名、フィールド名、エイリアス名」節を参照のこと。

テーブル参照は、tbl_name AS alias_name又はtbl_name alias_nameを使って別名を使用することが可能です:

mysql> SELECT t1.name, t2.salary FROM employee AS t1, info AS t2
    ->        WHERE t1.name = t2.name;
mysql> SELECT t1.name, t2.salary FROM employee t1, info t2
    ->        WHERE t1.name = t2.name;

出力用に選択されたフィールドは、ORDER BY節やGROUP BY節において、フィールド名、フィールドのエイリアス名、又はフィールド番号にて指し示すことができます。フィールド番号は1から始まります。
```
mysql> SELECT college, region, seed FROM tournament
    ->        ORDER BY region, seed;
mysql> SELECT college, region AS r, seed AS s FROM tournament
    ->        ORDER BY r, s;
mysql> SELECT college, region, seed FROM tournament
    ->        ORDER BY 2, 3;
```
逆順で並べたい場合には、 ORDER BY 節の中で、あなたが並べたいと思っているフィールドの名前の後ろに、 DESC (descending) キーワードを追加します。デフォルトは昇順です；これは ASC キーワードを指定したことになります。
WHERE 節で MySQL がサポートする任意の関数を使用することができます。「6.3 SELECT と WHERE 節で使用する関数」節参照.
HAVING節は、select_expressionにおいてどのフィールドの名前やエイリアス名でも指し示すことができます。これは最後に適用され、クライアントにアイテムが送られる直前に実行されるので、最適化されません。 WHERE節で書くべきものにHAVINGを用いてはいけません。例えば、次のように書いてはいけません:
```
mysql> SELECT col_name FROM tbl_name HAVING col_name > 0;
```
その代わりに、次のように書いてください:
```
mysql> SELECT col_name FROM tbl_name WHERE col_name > 0;
```
MySQL バージョン 3.22.5以降では、次のようにクエリを記述することができます:
```
mysql> SELECT user,MAX(salary) FROM users
           GROUP BY user HAVING MAX(salary)>10;
```
MySQLの古いバージョンでは、この代わりに次のように記述できます:
```
mysql> SELECT user,MAX(salary) AS sum FROM users
           GROUP BY user HAVING sum>10;
```
The options DISTINCT, DISTINCTROW and ALL specify whether duplicate rows should be returned. The default is (ALL), all matching rows are returned. DISTINCT and DISTINCTROW are synonyms and specify that duplicate rows in the result set should be removed.
SQL_SMALL_RESULT, SQL_BIG_RESULT, SQL_BUFFER_RESULT, STRAIGHT_JOIN, HIGH_PRIORITY は ANSI SQL に対する MySQL 拡張です。
HIGH_PRIORITY は、テーブルの更新よりも SELECT を優先させます。これは一度で完了する、とても速いクエリにのみ適用すべきです。もしリードロックされているテーブルがあったとし、たとえ update 文がこのテーブルの解除を待っていたとしても、 SELECT HIGH_PRIORITY クエリは実行されます。
SQL_BIG_RESULT は GROUP BY や DISTINCT と共に使用する事ができ、結果セットが多くのレコードを持つことをオプティマイザに知らせます。この場合、必要なら MySQL はディスクベースの一時テーブルを直接使用します。MySQL はこの場合、GROUP BY 要素上のキーで一時テーブルを行なう代わりにソートを行なうことを選択します。
SQL_BUFFER_RESULT は結果を一時テーブルへ強制的に置きます。これは MySQL がテーブルロックを速く解放して、クライアントに結果セットを送るために長い時間が掛かる場合の助けになります。
SQL_CALC_FOUND_ROWS (version 4.0.0 and up) tells MySQL to calculate how many rows there would be in the result set, disregarding any LIMIT clause. The number of rows can then be retrieved with SELECT FOUND_ROWS(). 「6.3.6.2 その他の関数」節参照. Please note that in versions prior to 4.1.0 this does not work with LIMIT 0, which is optimised to return instantly (resulting in a row count of 0). 「5.2.8 MySQL はどのように LIMIT を最適化するか？」節参照.
SQL_CACHE tells MySQL to store the query result in the query cache if you are using QUERY_CACHE_TYPE=2 (DEMAND). 「6.9 MySQL Query Cache (4.0.1以上)」節参照.
SQL_NO_CACHE tells MySQL to not allow the query result to be stored in the query cache. 「6.9 MySQL Query Cache (4.0.1以上)」節参照.
SQL_SMALL_RESULT (MySQL 固有のオプション) は GROUP BY か DISTINCT と共に使用する事ができ、結果セットが小さくなることをオプティマイザに知らせます。この場合、 MySQL はソートする代わりに、速い一時テーブルを結果の保存のために使用します。 MySQL バージョン 3.23 では、これは通常必要ではありません。
GROUP BY を使用する場合、GROUP BY 内のすべてのフィールドを ORDER BY に記述したかのように、出力レコードは GROUP BY に従ってソートされます。MySQL は、ASC と DESC を GROUP BY に記述できるように、GROUP BY を拡張しています:
```
SELECT a,COUNT(b) FROM test_table GROUP BY a DESC
```
MySQL は、GROUP BY 節に記述されていないフィールドを select できるように GROUP BY の使用を拡張しています。あなたのクエリから期待した結果を得ない場合、GROUP BY の説明を読んでください。「6.3.6.3 Functions for Use with GROUP BY Clauses」節参照.
STRAIGHT_JOINは、FROM節にて記述されたテーブルの順序に従って結合するよう、オプティマイザに強制します。オプティマイザが、テーブルを最適な順序で結合しない場合に、クエリのスピードアップのためにこれを使用することが可能です。「5.2.1 EXPLAIN 構文 (SELECTについての情報を得る)」節参照.
LIMIT 節は、 SELECT 構文で返されるレコード数を指定するのに使用されます。 LIMIT は一つか二つの数字の引数を取ります。引数が2つ与えられたならば、最初の引数は最初のレコードからのオフセットを示し、 2つめの引数は返すレコードの最大数を示します。初めのレコードのオフセットは0です(1ではありません)。 To be compatible with PostgreSQL MySQL also supports the syntax: LIMIT # OFFSET #.
```
mysql> SELECT * FROM table LIMIT 5,10;  # 6～15行目を返す
```
To retrieve all rows from a certain offset upto the end of the result set, you can use -1 for the second parameter:
```
mysql> SELECT * FROM table LIMIT 95,-1; # Retrieve rows 96-last.
```
もし引数が一つなら、返すべきレコードの最大行数を指定したことになります。
```
mysql> SELECT * FROM table LIMIT 5;     # 最初の5行を取り出す
```
いいかえれば、LIMIT n は LIMIT 0,n と同じです。
SELECTの書式、SELECT ... INTO OUTFILE 'file_name'は、選択されたレコードをファイルに書き込みます。ファイルはサーバ機に作成され、既に存在するファイルであってはなりません (`/etc/passwd'のようなファイルの破壊を防止します)。 SELECT ... INTO OUTFILE は主に、サーバマシン上でとても速くテーブルをダンプすることを意図されています。サーバホストでない別のホスト上で結果ファイルを生成したい場合は、SELECT ... INTO OUTFILE を使用できません。この場合は代わりに、mysqldump --tab や mysql -e "SELECT ..." > outfile のようなクライアントプログラムを使用して、ファイルを生成すべきです。 SELECT ... INTO OUTFILEは、LOAD DATA INFILEの逆です。 export_optionsの構文は、LOAD DATA INFILEステートメントの一部で使われるFIELDS節やLINES節と同じような構成です。「6.4.9 LOAD DATA INFILE 構文」節参照. 結果として取り出されるテキストファイルでは、以下に示す文字が ESCAPED BY 指定の文字によってエスケープされます：
- ESCAPED BY 文字自身
- FIELDS TERMINATED BY の最初の文字
- LINES TERMINATED BY の最初の文字
さらに、 ASCII 0 は、ESCAPED BY 0 (ASCII 48) にコンバートされます。いかなる FIELDS TERMINATED BY, ESCAPED BY, LINES TERMINATED BY 指定されている文字も、エスケープしなければならない理由は、テキストファイルを読み返せれるようにするためなのです。 ASCII 0 はいくつかのページャーでも見れるようにするためにエスケープされるのです。結果のファイルは SQL の文を含んでいないので、何もエスケープする必要はありません。次は、多くの古いプログラムによって使用されるフォーマットでファイルを得る例です。
```
SELECT a,b,a+b INTO OUTFILE "/tmp/result.text"
FIELDS TERMINATED BY ',' OPTIONALLY ENCLOSED BY '"'
LINES TERMINATED BY "\n"
FROM test_table;
```
INTO OUTFILE の代わりに INTO DUMPFILE を使用すると、 MySQL はファイルに１レコードだけを書きます。フィールドや行の終端とすべてのエスケープを含みません。これはファイル内に BLOB を格納したい場合に便利です。
Note that any file created by INTO OUTFILE and INTO DUMPFILE is going to be writeable for all users! The reason is that the MySQL server can't create a file that is owned by anyone else than the user it's running as (you should never run mysqld as root), the file has to be world-writeable so that you can manipulate it.
ページ／レコードロックとともにストレ-ジ・エンジン上で FOR UPDATE を使用すると、検査されるレコードは書き込みロックされます。

6.4.1.1 `JOIN` 構文

MySQLは、以下に示すSELECTステートメントにおけるJOIN構文をサポートします:

table_reference, table_reference
table_reference [CROSS] JOIN table_reference
table_reference INNER JOIN table_reference join_condition
table_reference STRAIGHT_JOIN table_reference
table_reference LEFT [OUTER] JOIN table_reference join_condition
table_reference LEFT [OUTER] JOIN table_reference
table_reference NATURAL [LEFT [OUTER]] JOIN table_reference
{ OJ table_reference LEFT OUTER JOIN table_reference ON conditional_expr }
table_reference RIGHT [OUTER] JOIN table_reference join_condition
table_reference RIGHT [OUTER] JOIN table_reference
table_reference NATURAL [RIGHT [OUTER]] JOIN table_reference

Where table_reference is defined as:

table_name [[AS] alias] [[USE INDEX (key_list)] | [IGNORE INDEX (key_list)] | [FORCE INDEX (key_list)]]

and join_condition is defined as:

ON conditional_expr |
USING (column_list)

You should generally not have any conditions in the ON part that are used to restrict which rows you have in the result set (there are exceptions to this rule). If you want to restrict which rows should be in the result, you have to do this in the WHERE clause.

注意: 3.23.17 より前のバージョンでは、INNER JOIN は join_condition を取りません！

上に示す最後のLEFT OUTER JOIN構文は、ODBCとの互換性のためだけに存在します:

table referenceは、tbl_name AS alias_nameやtblname alias_nameによる別名を指定することができます:
```
mysql> SELECT t1.name, t2.salary FROM employee AS t1, info AS t2
    ->        WHERE t1.name = t2.name;
```
INNER JOINと, (コンマ)は、同義語です。どちらも使用されるテーブル間の直積をとります。通常はWHERE条件にて、テーブルがどのようにリンクされるべきかを定義します。
ON条件節は、WHERE節で使用されるような条件文の書式です。
もし、LEFT JOIN の ON や USING において右側のテーブルにマッチするレコードが無かった場合、全てのフィールドがNULLである1つのレコードが、右側のテーブルとして使用されます。この事実は、あるテーブルについて、他のテーブルに対応するレコードが存在しないレコードを探すということに利用できます:
```
mysql> SELECT table1.* FROM table1
    ->        LEFT JOIN table2 ON table1.id=table2.id
    ->        WHERE table2.id IS NULL;
```
この例は、table1の内、idの値がtable2に存在しない全てのレコードを検索します。 (即ち、table2内のレコードと一致しないtable1の全てのレコード。) もちろん、この場合のtable2.idは、NOT NULLと定義されているものと仮定します。「5.2.6 MySQL はどのように LEFT JOIN と RIGHT JOIN を最適化するか？」節参照.
USING (column_list)節のフィールド名リストは、両方のテーブルに存在しなければなりません。USING節が次のように:
```
A LEFT JOIN B USING (C1,C2,C3,...)
```
定義されることは、ON式がこのように定義されるのと同義です:
```
A.C1=B.C1 AND A.C2=B.C2 AND A.C3=B.C3,...
```
同じフィールド名を持つ2つのテーブルの NATURAL [LEFT] JOIN は、 USING 節を伴った INNER JOIN や LEFT JOIN と同じとして定義されます。
INNER JOIN and , (comma) are semantically equivalent. Both do a full join between the tables used. Normally, you specify how the tables should be linked in the WHERE condition.
RIGHT JOIN works analogously as LEFT JOIN. To keep code portable across databases, it's recommended to use LEFT JOIN instead of RIGHT JOIN.
STRAIGHT_JOINは、右側のテーブルの前に、常に左側のテーブルを読むことを除けば、JOINと全く同じことです。これは、結合オプティマイザが、不当な順序でテーブルを出力するようなまれな事態に使用できます。
MySQL バージョン 3.23.12 から、テーブルから情報を取り出す時に、 MySQL がどのインデックスを使用すべきかというヒントを与えることができるようになりました。これは、MySQL が間違ったインデックスを使用していることを EXPLAIN が示す場合に有用です。USE INDEX (key_list) を指定することによって、テーブルからレコードを見つけるために、指定されたインデックスの一つだけを使用するように MySQL に伝えることができます。別の構文 IGNORE INDEX (key_list) は、MySQL に特定のインデックスを使用しないように伝えるために使用できます。 In MySQL 4.0.9 you can also use FORCE INDEX. This acts likes USE INDEX (key_list) but with the addition that a table scan is assumed to be VERY expensive. In other words a table scan will only be used if there is no way to use one of the given index to find rows in the table. USE/IGNORE KEY are synonyms for USE/IGNORE INDEX.

例:

mysql> SELECT * FROM table1,table2 WHERE table1.id=table2.id;
mysql> SELECT * FROM table1 LEFT JOIN table2 ON table1.id=table2.id;
mysql> SELECT * FROM table1 LEFT JOIN table2 USING (id);
mysql> SELECT * FROM table1 LEFT JOIN table2 ON table1.id=table2.id
    ->          LEFT JOIN table3 ON table2.id=table3.id;
mysql> SELECT * FROM table1 USE INDEX (key1,key2)
    ->          WHERE key1=1 AND key2=2 AND key3=3;
mysql> SELECT * FROM table1 IGNORE INDEX (key3)
    ->          WHERE key1=1 AND key2=2 AND key3=3;

「5.2.6 MySQL はどのように LEFT JOIN と RIGHT JOIN を最適化するか？」節参照.

6.4.1.2 `UNION` Syntax

SELECT ...
UNION [ALL]
SELECT ...
  [UNION
   SELECT ...]

UNION is implemented in MySQL 4.0.0.

UNION is used to combine the result from many SELECT statements into one result set.

The columns listed in the select_expression portion of the SELECT should have the same type. The column names used in the first SELECT query will be used as the column names for the results returned.

The SELECT commands are normal select commands, but with the following restrictions:

Only the last SELECT command can have INTO OUTFILE.

If you don't use the keyword ALL for the UNION, all returned rows will be unique, as if you had done a DISTINCT for the total result set. If you specify ALL, then you will get all matching rows from all the used SELECT statements.

If you want to use an ORDER BY for the total UNION result, you should use parentheses:

(SELECT a FROM table_name WHERE a=10 AND B=1 ORDER BY a LIMIT 10)
UNION
(SELECT a FROM table_name WHERE a=11 AND B=2 ORDER BY a LIMIT 10)
ORDER BY a;

6.4.2 `HANDLER` Syntax

HANDLER tbl_name OPEN [ AS alias ]
HANDLER tbl_name READ index_name { = | >= | <= | < } (value1,value2,...)
    [ WHERE ... ] [LIMIT ... ]
HANDLER tbl_name READ index_name { FIRST | NEXT | PREV | LAST }
    [ WHERE ... ] [LIMIT ... ]
HANDLER tbl_name READ { FIRST | NEXT }
    [ WHERE ... ] [LIMIT ... ]
HANDLER tbl_name CLOSE

The HANDLER statement provides direct access to the MyISAM table storage engine interface.

The first form of HANDLER statement opens a table, making it accessible via subsequent HANDLER ... READ statements. This table object is not shared by other threads and will not be closed until the thread calls HANDLER tbl_name CLOSE or the thread dies.

The second form fetches one row (or more, specified by LIMIT clause) where the index specified complies to the condition and WHERE condition is met. If the index consists of several parts (spans over several columns) the values are specified in comma-separated list, providing values only for few first columns is possible.

The third form fetches one row (or more, specified by LIMIT clause) from the table in index order, matching WHERE condition.

The fourth form (without index specification) fetches one row (or more, specified by LIMIT clause) from the table in natural row order (as stored in datafile) matching WHERE condition. It is faster than HANDLER tbl_name READ index_name when a full table scan is desired.

HANDLER ... CLOSE closes a table that was opened with HANDLER ... OPEN.

HANDLER is a somewhat low-level statement. For example, it does not provide consistency. That is, HANDLER ... OPEN does NOT take a snapshot of the table, and does NOT lock the table. This means that after a HANDLER ... OPEN is issued, table data can be modified (by this or any other thread) and these modifications may appear only partially in HANDLER ... NEXT or HANDLER ... PREV scans.

The reasons to use this interface instead of normal SQL are:

It's faster than SELECT because:
- A designated storage engine is allocated for the thread in HANDLER OPEN.
- There is less parsing involved.
- No optimiser and no query checking overhead.
- The used table doesn't have to be locked between two handler requests.
- The handler interface doesn't have to provide a consistent look of the data (for example, dirty-reads are allowed), so the storage engine can do optimisations that SQL doesn't normally allow.
It makes it much easier to port applications that uses an ISAM like interface to MySQL.
It allows one to traverse a database in a manner that is not easy (in some case impossible) to do with SQL. The handler interface is more natural way to look at data when working with applications that provide an interactive user interfaces to the database.

6.4.3 `INSERT` 構文

    INSERT [LOW_PRIORITY | DELAYED] [IGNORE]
        [INTO] tbl_name [(col_name,...)]
        VALUES ((expression | DEFAULT),...),(...),...
        [ ON DUPLICATE KEY UPDATE col_name=expression, ... ]
or  INSERT [LOW_PRIORITY | DELAYED] [IGNORE]
        [INTO] tbl_name [(col_name,...)]
        SELECT ...
or  INSERT [LOW_PRIORITY | DELAYED] [IGNORE]
        [INTO] tbl_name
        SET col_name=(expression | DEFAULT), ...
        [ ON DUPLICATE KEY UPDATE col_name=expression, ... ]

INSERTは、既存のテーブルに新しいレコードを挿入します。 INSERT ... VALUES書式は、値の明示指定を基本としてレコードを挿入します。 INSERT ... SELECT書式は、他の表(複数可)から抽出したレコードを挿入します。複数の値リストを用いるINSERT ... VALUES書式は、 MySQL バージョン 3.22.5以降でサポートされています。 col_name=expression構文は、 MySQL バージョン 3.22.10以降でサポートされています。

tbl_nameは、レコードを挿入するテーブルです。フィールド名リストは、後続の値定義ステートメントのフィールドを指し示します:

もしいかなるフィールドも INSERT ... VALUES や INSERT ... SELECT などで明示しなければ、全てのフィールドの値が VALUES() の中に与えられなくてはなりません。テーブル内のフィールド順が不明な場合、これを調べるためにDESCRIBE tbl_nameを使用して下さい。
テーブル内の一部のフィールドしか指定しない場合、指定されなかったフィールドには、それぞれの初期値が指定されます。初期値の割当ては、「6.5.3 CREATE TABLE 構文」節. で述べられています。 You can also use the keyword DEFAULT to set a column to its default value. (New in MySQL 4.0.3.) This makes it easier to write INSERT statements that assign values to all but a few columns, because it allows you to avoid writing an incomplete VALUES() list (a list that does not include a value for each column in the table). Otherwise, you would have to write out the list of column names corresponding to each value in the VALUES() list. MySQL always has a default value for all fields. This is something that is imposed on MySQL to be able to work with both transactional and not transactional tables. Our view is that checking of fields content should be done in the application and not in the database server.
expressionは、値リスト内で先頭に近い方のフィールドを参照しなければなりません。例えば、次のように記述できます:
```
mysql> INSERT INTO tbl_name (col1,col2) VALUES(15,col1*2);
```
しかし、次のようには記述できません:
```
mysql> INSERT INTO tbl_name (col1,col2) VALUES(col2*2,15);
```
キーワードLOW_PRIORITYを指定した場合、INSERTの実行はそのテーブルから値を読み込むクライアントがいなくなるまで遅らされます。この場合、クライアントは insert 文が完了するまで待たされます。テーブルが頻繁に使用される場合、長い時間かかります。これはクライアントを一度に継続させる INSERT DELAYED と対称的です。「6.4.4 INSERT DELAYED 構文」節参照. Note that LOW_PRIORITY should normally not be used with MyISAM tables as this disables concurrent inserts. 「7.1 MyISAM テーブル (3.23.0以上)」節参照.
もし IGNORE キーワードを INSERT に値とともに与えるなら、テーブル内の PRIMARY や UNIQUE キーにすでに存在する重複したものは無視され、挿入されません。多重行の値を含むレコードの INSERT にキーワード IGNORE を指定しない場合、テーブルの PRIMARY キーや UNIQUE キーに重複が起こる際に、挿入処理が異常終了します。 IGNORE を指定した場合、重複するキー値を持つレコードは挿入されません。 C API 関数 mysql_info() により、テーブルにいくつのレコードが挿入されたかチェックすることができます。
If you specify ON DUPLICATE KEY UPDATE clause (new in MySQL 4.1.0), and a row is inserted that would cause a duplicate value in PRIMARY or UNIQUE key, an UPDATE of the old row is performed. For example, the command:
```
mysql> INSERT INTO table (a,b,c) VALUES (1,2,3)
   --> ON DUPLICATE KEY UPDATE c=c+1;
```
in case of column a is declared as UNIQUE and already holds 1 once, would be identical to the
```
mysql> UPDATE table SET c=c+1 WHERE a=1;
```
Note: that if column b is unique too, the UPDATE command would be written as
```
mysql> UPDATE table SET c=c+1 WHERE a=1 OR b=2 LIMIT 1;
```
and if a=1 OR b=2 matches several rows, only one row will be updated! In general, one should try to avoid using ON DUPLICATE KEY clause on tables with multiple UNIQUE keys. When one uses ON DUPLICATE KEY UPDATE, the DELAYED option is ignored.
MySQLが、DONT_USE_DEFAULT_FIELDSオプションにより制限されていた場合、NULL値を許さない全てのフィールドに明示的に値をしないと INSERTステートメントは、エラーを生成します。「2.3.3 典型的な configure オプション」節参照.
mysql_insert_id 関数で AUTO_INCREMENT フィールドに使用された値を見つけることができます。「8.4.3.130 mysql_insert_id()」節参照.

多重の値リストを持つ INSERT ... SELECT ... 又は INSERT ... VALUES() ステートメントを使用する場合、クエリーに関する情報を得るために C API関数 mysql_info() を使用することができます。その情報の書式は以下に示す文字列のようになります:

Records: 100 Duplicates: 0 Warnings: 0

Duplicatesは、既に存在するユニークインデックスの値と重複することにより、挿入できなかったレコード数を表します。 Warningsは、挿入されたフィールドが何らかの疑わしい値であったという数を表します。警告は、次のような条件の下で発生します:

NOT NULL定義されたフィールドへのNULLの挿入。フィールドには初期値が設定されます。
数値フィールドの範囲を超える値のセット。値は範囲内の限界値に補正されます。
数値フィールドへの `10.34 a' のような値のセット。引きずっているゴミは取り除かれ、残りの数値部分が挿入されます。値が数値として判断できなかった場合、フィールドには 0 がセットされます。
CHAR、VARCHAR、VARCHAR、TEXT又はBLOB フィールドへの最大長を超える文字列の挿入。値はフィールドの最大長に切り捨てられます。
日付又は時刻フィールドへのフィールド属性に反した挿入。その属性に適した ``ゼロ''値がセットされます。

6.4.3.1 `INSERT ... SELECT` 構文

INSERT [LOW_PRIORITY] [IGNORE] [INTO] tbl_name [(column list)] SELECT ...

With INSERT ... SELECT statement you can quickly insert many rows into a table from one or many tables.

INSERT INTO tblTemp2 (fldID) SELECT tblTemp1.fldOrder_ID FROM tblTemp1 WHERE
tblTemp1.fldOrder_ID > 100;

The following conditions hold for an INSERT ... SELECT statement:

The target table of the INSERT statement cannot appear in the FROM clause of the SELECT part of the query because it's forbidden in ANSI SQL to SELECT from the same table into which you are inserting. (The problem is that the SELECT possibly would find records that were inserted earlier during the same run. When using subquery clauses, the situation could easily be very confusing!)
AUTO_INCREMENT columns work as usual.
You can use the C API function mysql_info() to get information about the query. 「6.4.3 INSERT 構文」節参照.
To ensure that the update log/binary log can be used to re-create the original tables, MySQL will not allow concurrent inserts during INSERT ... SELECT.

You can of course also use REPLACE instead of INSERT to overwrite old rows.

6.4.4 `INSERT DELAYED` 構文

INSERT DELAYED ...

INSERT 構文の DELAYED オプションは MySQL 独自のオプションで、これは INSERT が完全に終了することを待てないクライアントを持つ場合に、とても役立ちます。これは、ロギングのために MySQL を使用する時の一般的な問題で、完了に長い時間がかかる SELECT ステートメントも定期的に実行できます。 DELAYED は MySQL 3.22.15 で導入されました。これは ANSI SQL92 に対する MySQL 拡張です。

INSERT DELAYED only works with ISAM and MyISAM tables. Note that as MyISAM tables supports concurrent SELECT and INSERT, if there is no free blocks in the middle of the datafile, you very seldom need to use INSERT DELAYED with MyISAM. 「7.1 MyISAM テーブル (3.23.0以上)」節参照.

INSERT DELAYED を使用する時、クライアントは一度 ok となり、テーブルが他のスレッドで使用中でない時にレコードが挿入されます。

INSERT DELAYED を使用して得られるほかの利益は、多くのクライアントからの insert が同時に束ねられ、一つのブロックで書かれることです。これは多くの別々の insert を実行するよりとても速くなります。

現在、キューイングされたレコードは、それらがテーブルに代入されるまでメモリーに保持されているだけです。これは、もし mysqld を強引な方法 (kill -9) でキルしたり、 mysqld が予期せず死んだ場合、キューイングされているレコードはディスクに書かれず失われます！

DELAYED オプションを INSERT や REPLACE で使用する場合、以下のことがおきます。ここで ``スレッド'' とは INSERT DELAYED コマンドを受けたスレッドをさし、 ``ハンドラー'' とは特定のテーブルのための全ての INSERT DELAYED 構文を操作するスレッドを指します。

スレッドがあるテーブルに対し DELAYED 構文を実行するとき、そのテーブルに対する全ての DELAYED 構文を処理するためにハンドラースレッドが作成されます。もしそのようなハンドラーが存在していない場合には。
そのスレッドは、そのハンドラーが DELAYED ロックを既に持っているかどうかをチェックします；もし持っていないなら、そうするようにハンドラーに告げます。たとえ他のスレッドが READ か WRITE ロックをそのテーブルに持っていたとしても、 DELAYED ロックを得ることができます。しかし、そのハンドラーは全ての ALTER TABLE ロックか FLUSH TABLES を待ちます。そのテーブル構造が最新であるのを確実にするために。
スレッドは INSERT ステートメントを実行しますが、レコードをテーブルに書く代わりに、ハンドラスレッドによって管理されるキューに最後のレコードのコピーを置きます。文法エラーはスレッドによって通知され、クライアントプログラムに報告されます。
クライアントは結果行の重複数や AUTO_INCREMENT の値を報告できません；それはサーバーから得ることができません。なぜなら、 INSERT はインサートオペレーションが完全に終了する前に返るからです。もし C API を使用しているなら、 mysql_info() 関数は同様の理由によりなにも返しません。
更新ログは、レコードがそのテーブルに insert されたとき、そのハンドラースレッドによって更新されます。複数レコードの挿入の場合、更新ログは最初の行が挿入されたときに更新されます。
それぞれの delayed_insert_limit レコードが書かれた後、そのハンドラーはいかなる SELECT 文もまだ延期されていないかを確認します。もしそうなら、続ける前にこれらに対して実行を可能にします。
ハンドラーのキュー内にレコードがなくなったとき、テーブルはアンロックされます。もし新しい INSERT DELAYED コマンドが delayed_insert_timeout 秒以内に受け付けられなければ、ハンドラーは終了します。
もし、特定のハンドラーのキュー内に delayed_queue_size 以上のレコードが既に延期されているならば、そのスレッドは、キューに余裕がある間待ちます。これは mysqld サーバーが delayed されたキューに全てのメモリーを確実に使用しないようにするのに役立ちます。
そのハンドラースレッドは MySQL プロセスリストの Command 項内に、 delayed_insert と共に表示されます。これは FLUSH TABLES コマンドか KILL thread_id を実行することで、 kill できるでしょう。しかし、これらは、終了する前に、キュー内の全てのレコードをテーブルに保存しようとします。この間、このスレッドは、他のスレッドから来たいかなる新しい INSERT コマンドも受け付けません。もし、この後に INSERT DELAYED コマンドを実行するなら、新しいハンドラースレッドが作成されます。上記のことは、もし INSERT DELAYED コマンドが既に走っているなら、 INSERT DELAYED コマンドは、普通の INSERT コマンドよりも高い優先度を持つということです！他の update コマンドは INSERT DELAY キューが空になるまで、あるいは誰かが KILL thread_id や FLUSH TABLES を実行してハンドラーをキルするまで、待たされます。

以下のステータス変数は INSERT DELAYED コマンドについての情報を与えます：

Variable	Meaning
`Delayed_insert_threads`	ハンドラースレッドの数
`Delayed_writes`	`INSERT DELAYED` で書かれるレコード数
`Not_flushed_delayed_rows`	書き込みを待つレコード数

これらの変数は SHOW STATUS 構文を発行したり mysqladmin extended-status コマンドを実行することで見れます.

注意: INSERT DELAYED は、テーブルが使用中でない場合、通常の INSERT よりも遅くなります。INSERT DELAYED を使用する各テーブルについて別のスレッドを操作するサーバの、追加のオーバーヘッドもあります。これは、確実にそれを必要とする時にだけ INSERT DELAYED を使用すべきことを意味します！

6.4.5 `UPDATE` 構文

UPDATE [LOW_PRIORITY] [IGNORE] tbl_name
    SET col_name1=expr1 [, col_name2=expr2 ...]
    [WHERE where_definition]
    [ORDER BY ...]
    [LIMIT rows]

or

UPDATE [LOW_PRIORITY] [IGNORE] tbl_name [, tbl_name ...]
    SET col_name1=expr1 [, col_name2=expr2 ...]
    [WHERE where_definition]

UPDATE はテーブルに存在するレコードのフィールドを、新しい値に更新します。 SET 節はどのフィールドをどういった値にすべきかを示します。 WHERE 節が与えられた場合、更新すべきレコードを特定することになります。それ以外は、全てのレコードを更新します。 ORDER BY 節が指定された場合、レコードは指定された順に更新されます。

LOW_PRIORITY キーワードを指定した場合、UPDATE の実行は、テーブルを読んでいるクライアントがなくなるまで、遅らされます。

IGNORE キーワードを指定した場合は、update 文は、 update 中に二重キーのエラーを得たとしても、異常終了しません。衝突を引き起こすレコードは更新されません。

表記中の tbl_name からのフィールドをアクセスすると、UPDATE は現在のフィールド値を使用します。例えば、次のステートメントは age フィールドにその現在値より１大きい値を設定します:

mysql> UPDATE persondata SET age=age+1;

UPDATE は左から右に評価されます。例えば、以下の文は age フィールドを 2倍にし、そのあと1増やします：

mysql> UPDATE persondata SET age=age*2, age=age+1;

もしフィールドに現在もっている値を指定した場合、MySQL はそれを通知し、値は更新しません。

UPDATE は変更されたレコード数を返します。 MySQL バージョン 3.22 以上では、C API 関数 mysql_info() がマッチし更新されたレコード数を返します。また UPDATE 中に起きたワーニングの数も返します。

MySQL バージョン 3.23 では、 LIMIT # で指定した数だけレコードを変更できます。

Starting with MySQL Version 4.0.4, you can also perform UPDATE operations that cover multiple tables:

UPDATE items,month SET items.price=month.price
WHERE items.id=month.id;

Note: you can not use ORDER BY or LIMIT with multi-table UPDATE.

6.4.6 `DELETE` 構文

DELETE [LOW_PRIORITY] [QUICK] FROM table_name
       [WHERE where_definition]
       [ORDER BY ...]
       [LIMIT rows]

or

DELETE [LOW_PRIORITY] [QUICK] table_name[.*] [, table_name[.*] ...]
       FROM table-references
       [WHERE where_definition]

or

DELETE [LOW_PRIORITY] [QUICK]
       FROM table_name[.*] [, table_name[.*] ...]
       USING table-references
       [WHERE where_definition]

DELETEは、tbl_nameより、where_definitionにて与えられた条件を満たすレコードを削除し、削除されたレコード数を返します。

WHERE節を指定することなしにDELETEを発行した場合、全てのレコードが削除されます。もし AUTOCOMMIT モードでこの操作を実行するならば、これは TRUNCATE と同様に動作します。「6.4.7 TRUNCATE 構文」節参照. MySQL 3.23では、DELETE は削除したレコード数を 0 で返します。

もし全てのレコードを削除している時に、いくつのレコードが消され、いくつのレコードがスピードを犠牲にしているのか、本当に知りたいならば、 DELETE 構文を以下のように使用します：

mysql> DELETE FROM tbl_name WHERE 1>0;

これは DELETE FROM tbl_name を WHERE 節なしで行うよりも、とても遅いです。なぜなら一度で消そうとするからです。

キーワードLOW_PRIORITYを指定した場合、そのテーブルを読んでいるクライアントがいなくなるまでDELETEの実行は遅らせられます。

削除されたレコードはリンクリストで維持され、次のINSERT操作は、古いレコード位置を再利用します。ファイルをより小さくしたい場合は、OPTIMIZE TABLEステートメントかテーブルの再編成のためにmyisamchkユティリティを使用してください。 OPTIMIZE TABLEの方が簡単ですが、myisamchkの方が早く動作します。「4.5.1 OPTIMIZE TABLE 構文」節参照.

If you specify the word QUICK then the storage engine will not merge index leaves during delete, which may speed up certain kind of deletes.

The first multi-table delete format is supported starting from MySQL 4.0.0. The second multi-table delete format is supported starting from MySQL 4.0.2.

The idea is that only matching rows from the tables listed before the FROM or before the USING clause are deleted. The effect is that you can delete rows from many tables at the same time and also have additional tables that are used for searching.

The .* after the table names is there just to be compatible with Access:

DELETE t1,t2 FROM t1,t2,t3 WHERE t1.id=t2.id AND t2.id=t3.id

or

DELETE FROM t1,t2 USING t1,t2,t3 WHERE t1.id=t2.id AND t2.id=t3.id

In the above case we delete matching rows just from tables t1 and t2.

If an ORDER BY clause is used (available from MySQL 4.0), the rows will be deleted in that order. This is really only useful in conjunction with LIMIT. For example:

DELETE FROM somelog
WHERE user = 'jcole'
ORDER BY timestamp
LIMIT 1

This will delete the oldest entry (by timestamp) where the row matches the WHERE clause.

MySQL-特化 DELETE の LIMIT rows オプションはサーバーに消す最大のレコード数をつげます。これは DELETE コマンドがあまりに多くの時間を取らないために使用されます。 LIMIT 値よりも affected row の数が少なくなるまで、単純に DELETE コマンドを繰り返すだけです。

From MySQL 4.0, you can specify multiple tables in the DELETE statement to delete rows from one table depending on a particular condition in multiple tables. However, you can not use ORDER BY or LIMIT in a multi-table DELETE.

6.4.7 `TRUNCATE` 構文

TRUNCATE TABLE table_name

3.23 では、COMMIT ; DELETE FROM table_name と同じことです。「6.4.6 DELETE 構文」節参照.

TRUNCATE TABLE differs from DELETE FROM ... in the following ways:

Truncate はテーブルを破棄して再生成するように実装されています。これは多くのレコードを削除する時により速くなります。
トランザクション安全ではありません; COMMIT が呼ばれたかのように TRUNCATE TABLE は自動的に現在のトランザクションを終了します。
削除したレコード数を返しません。
テーブル定義ファイル `table_name.frm' が正しい限り、たとえ、データやインデックスファイルが汚れても、テーブルはこの方法で再生成できます。

TRUNCATE は ORACLE SQL 拡張です。

6.4.8 `REPLACE` 構文

    REPLACE [LOW_PRIORITY | DELAYED]
        [INTO] tbl_name [(col_name,...)]
        VALUES (expression,...),(...),...
or  REPLACE [LOW_PRIORITY | DELAYED]
        [INTO] tbl_name [(col_name,...)]
        SELECT ...
or  REPLACE [LOW_PRIORITY | DELAYED]
        [INTO] tbl_name
        SET col_name=expression, col_name=expression,...

REPLACEは、テーブル中にある古いレコードの UNIQUE インデックスか PRIMARY KEY 上にある値が、新しいレコードと同じ場合に、新しいレコードを挿入する前に古いレコードを削除するということを除けば、INSERTと全く同じように動作します。「6.4.3 INSERT 構文」節参照.

In other words, you can't access the values of the old row from a REPLACE statement. In some old MySQL versions it appeared that you could do this, but that was a bug that has been corrected.

To be able to use REPLACE you must have INSERT and DELETE privileges for the table.

When you use a REPLACE command, mysql_affected_rows() will return 2 if the new row replaced an old row. This is because one row was inserted after the duplicate was deleted.

This fact makes it easy to determine whether REPLACE added or replaced a row: check whether the affected-rows value is 1 (added) or 2 (replaced).

Note that unless you use a UNIQUE index or PRIMARY KEY, using a REPLACE command makes no sense, since it would just do an INSERT.

6.4.9 `LOAD DATA INFILE` 構文

LOAD DATA [LOW_PRIORITY | CONCURRENT] [LOCAL] INFILE 'file_name.txt'
    [REPLACE | IGNORE]
    INTO TABLE tbl_name
    [FIELDS
        [TERMINATED BY '\t']
        [[OPTIONALLY] ENCLOSED BY '']
        [ESCAPED BY '\\' ]
    ]
    [LINES TERMINATED BY '\n']
    [IGNORE number LINES]
    [(col_name,...)]

LOAD DATA INFILEステートメントは、テキストファイルからテーブルへと、レコードを高速に読み込みます。 LOCAL キーワードが指定されれば、ファイルはクライアント・ホストから読み込まれます。 LOCALが指定されなければ、ファイルはサーバに位置する必要があります (LOCALは、MySQL バージョン 3.22.6以降で利用できます)。

セキュリティ上の理由から、サーバからテキストファイルを読み出す時は、ファイルがデータベースディレクトリに存在するか、全てに読み込み権限がある必要があります。また、サーバファイルで LOAD DATA INFILE を使用するには、データベースの FILE 権限も持たなければなりません。「4.2.7 MySQL が提供する権限」節参照.

In MySQL 3.23.49 and MySQL 4.0.2 LOCAL will only work if you have not started mysqld with --local-infile=0 or if you have not enabled your client to support LOCAL. 「4.2.4 Security issues with LOAD DATA LOCAL」節参照.

もし LOW_PRIORITY を指定した場合、LOAD DATA 構文はそのテーブルから他のクライアントが読み込みを行っている間、遅らされます。

If you specify the keyword CONCURRENT with a MyISAM table, then other threads can retrieve data from the table while LOAD DATA is executing. Using this option will of course affect the performance of LOAD DATA a bit even if no other thread is using the table at the same time.

LOCAL 使用をすると、クライアント・ホストからサーバ・ホストへファイルの内容が転送される分、多少遅くなるでしょう。いうならば、ローカルのファイルを読み込むのに、 FILE 権限は必要ないということです。

If you are using MySQL before Version 3.23.24 you can't read from a FIFO with LOAD DATA INFILE. If you need to read from a FIFO (for example the output from gunzip), use LOAD DATA LOCAL INFILE instead.

mysqlimportユティリティは、データファイルの読み込みに使用することができます。; これは、サーバにLOAD DATA INFILEコマンドを送信することによって処理を実現しています。 --localオプションは、mysqlimportに、クライアント・ホストからデータファイルを読み込ませます。クライアントとサーバが圧縮プロトコルをサポートしていれば、低速なネットワークでより良いパフォーマンスを得るために、--compressオプションを指定することができます。

サーバ・ホストにファイルを置く場合、サーバは、以下のルールを使用します:

完全なパスでファイル名が与えられた場合、サーバはパス名をそのまま使用します。
１つ又は複数の構成要素から成る相対パスと共にファイル名が与えられた場合、サーバは、サーバのデータディレクトリ以下からファイルを探します。
ファイル名だけが単に与えられた場合、サーバは、カレントのデータベースディレクトリを探します。

これらのルールは、ファイルが `myfile.txt' のように与えられればデータベースディレクトリからファイルが読み出され、 `./myfile.txt' のように与えられれば、現在選択しているデータベースのデータディレクトリからファイルが読み出されるという意味であることに注意して下さい。

例えば、以下の LOAD DATA 文は、`data.txt' ファイルを db1 データベースディレクトリから読みます。なぜなら、db1 は現在選択されているデータベースだからです。たとえ、db2 データベースのテーブルに、ファイルから読み込んだデータを挿入するとしても。：

以下に示すような構文では、ファイルは db1 データベースディレクトリから読まれます。db2 ではありません:

mysql> USE db1;
mysql> LOAD DATA INFILE "data.txt" INTO TABLE db2.my_table;

REPLACE と IGNORE キーワードは、すでに存在するユニークキーに重複しているレコードの入力に対する制御です。 REPLACE 指定の場合、同じユニークキーを持つ既存のレコードは新しいレコードで置き換えられます。 IGNORE 指定の場合、既存のレコードのユニークキーと重複するキーをもつ新しいレコードは飛ばされます。もし、どちらも指定しなかった場合、重複したキーが見つかった場合エラーが発生し、テキストファイルは無視されます。

LOCAL キーワードを使用してデータをローカルからロードする場合、サーバーは操作の途中で転送をとめる方法を知りません。それでデフォルトの動作としては IGNORE が指定されたのと同じになります。

If you use LOAD DATA INFILE on an empty MyISAM table, all non-unique indexes are created in a separate batch (like in REPAIR). This normally makes LOAD DATA INFILE much faster when you have many indexes.

LOAD DATA INFILEは、SELECT ... INTO OUTFILEの逆です。「6.4.1 SELECT 構文」節参照. データベースからファイルへデータを書き込むには、SELECT ... INTO OUTFILEを使用します。ファイルからデータベースに読み戻すには、LOAD DATA INFILEを使用します。 FIELDSとLINES節の構文は両方のコマンドとも同じです。どちらの節もオプションですが、両方を指定する場合は、FIELDSは、LINES より先に指定しなければなりません。

FIELDS節を指定した場合、その段落(TERMINATED BY、[OPTIONALLY] ENCLOSED BY及びESCAPED BY)は、少なくとも１つを指定しなければならないことを除いて、それらもまたオプションとなります。

FIELDS節を指定しなかった場合、初期値は以下のように記述したのと等価となります:

FIELDS TERMINATED BY '\t' ENCLOSED BY '' ESCAPED BY '\\'

LINES節を指定しなかった場合、初期値は以下のように記述したのと等価となります:

LINES TERMINATED BY '\n'

言い換えると、LOAD DATA INFILE の初期値は、出力へ書き込む際に以下のように振舞います:

改行をレコードの境界とみなす
タブ文字によってフィールドを区切る
クォート文字でフィールドを囲んでいないものとする
タブ文字や改行文字及び`\'の前に`\'があることにより、それらをフィールド値の一部のリテラル文字であるとして処理する。

逆に、LOAD DATA INFILEの初期値は、入力を読み込む際に以下のように振舞います:

フィールド間にタブ文字を書く
いずれのクォート文字でもフィールドを囲まない
`\'の使用により、フィールド値の中で使用するタブ文字や改行文字、`\'をエスケープする
レコードの終りに改行文字を書く

FIELDS ESCAPED BY '\\'と書いた場合、単一のバックスラッシュとして読み出される値とするために、２つのバックスラッシュを指定しなければならないことに注意して下さい。

IGNORE number LINES オプションはファイルの先頭にあるレコードを無視するのに使用されます：

mysql> LOAD DATA INFILE "/tmp/file_name" INTO TABLE test IGNORE 1 LINES;

データベースからファイルへデータを書き、それから後でそのファイルからデータベースへデータを読み戻すために、SELECT ... INTO OUTFILEと対にLOAD DATA IN FILEを使う場合、双方のフィールドとレコードの取扱いに関するオプションは、一致しなければなりません。さもなければ、LOAD DATA INFILEは適切にファイルを処理しないでしょう。フィールドをコンマで区切ってファイルへ書き出すために、SELECT ... INTO OUT FILEを使用するとすれば:

mysql> SELECT * INTO OUTFILE 'data.txt'
    ->          FIELDS TERMINATED BY ','
    ->          FROM ...;

コンマ区切りファイルから読み戻すため、正しいステートメントはこうなるでしょう:

mysql> LOAD DATA INFILE 'data.txt' INTO TABLE table2
    ->           FIELDS TERMINATED BY ',';

その代わりとして次に示すようなステートメントでファイルを読み込もうとしても、正しく動作しないでしょう。なぜなら、これは、LOAD DATA INFILEに対してフィールドの間にタブを探すよう指示するからです:

mysql> LOAD DATA INFILE 'data.txt' INTO TABLE table2
    ->           FIELDS TERMINATED BY '\t';

おそらく、それぞれの入力行は単一のフィールドとして処理されるでしょう。

LOAD DATA INFILEは外部ソースからもファイルを読み出すことができます。例えば、dBASEフォーマットのファイルは、フィールドをコンマで区切られ、ダブルクォーテーションで囲まれています。レコードが改行文字で区切られているとしたら、次に示すフィールド及びレコードの取扱オプションを指定したコマンドが、このようなファイルを読み込むのに使用できます。

mysql> LOAD DATA INFILE 'data.txt' INTO TABLE tbl_name
    ->           FIELDS TERMINATED BY ',' ENCLOSED BY '"'
    ->           LINES TERMINATED BY '\n';

いくつかのフィールド及びレコードの取扱オプションに、空文字列('')を指定することがあります。空でないなら、 FIELDS [OPTIONALLY] ENCLOSED BYとFIELDS ESCAPED BYの値は単一の文字でなければなりません。 FIELDS TERMINATED BYとLINES TERMINATED BYは２つ以上の文字となるでしょう。

例えば、リターン文字と改行文字のペアで区切られたレコードを書き込んだり、このようなレコードを含んだファイルを読み込んだりするには、 LINES TERMINATED BY '\r\n'節を指定します。

CREATE TABLE jokes (a int not null auto_increment primary key, joke text
not null);
LOAD DATA INFILE "/tmp/jokes.txt" INTO TABLE jokes FIELDS TERMINATED BY ""
LINES TERMINATED BY "\n%%\n" (joke);

FIELDS [OPTIONALLY] ENCLOSED BYは、フィールドの引用符を制御します。出力の際(SELECT ... INTO OUTFILE)、OPTIONALLY語を省いたなら、全てのフィールドはENCLOSED BY文字で囲まれます。このような出力(フィールド区切りにコンマを使用)の例を次に示します:

"1","a string","100.20"
"2","a string containing a , comma","102.20"
"3","a string containing a \" quote","102.20"
"4","a string containing a \", quote and comma","102.20"

OPTIONALLYを指定すれば、ENCLOSED BY文字は、 CHARフィールドとVARCHARフィールドのみ囲むのに使用されます:

1,"a string",100.20
2,"a string containing a , comma",102.20
3,"a string containing a \" quote",102.20
4,"a string containing a \", quote and comma",102.20

フィールド値の中におけるENCLOSED BY文字の出現は、ESCAPED BY文字をその前に置くことによりエスケープされることに注意して下さい。ESCAPED BY値に空を指定すると、LOAD DATA INFILEにより正しく読み込めない出力を生成するでしょう。例えば、このようにエスケープ文字を空にした場合、以下に示すような出力となります。４行目の２つ目のフィールドに、(誤って)フィールドを区切るかのようなクォートに続くコンマを含んでいることに注視して下さい:

1,"a string",100.20
2,"a string containing a , comma",102.20
3,"a string containing a " quote",102.20
4,"a string containing a ", quote and comma",102.20

入力において、ENCLOSED BY文字が指定されており、それがフィールド値の両端に現れた場合、その文字は取り去られます。(これは、OPTIONALLYが指定されたかどうかに拘らず、当てはまります;OPTIONALLYは入力解析には効果がありません。) ESCAPED BY文字を前置きされたENCLOSED BY文字の出現は、現在のフィールド値の一部として処理されます。具体的には、あるフィールドがそれ自身、たEN CLOSED BY文字で始まっている場合、フィールドらの内部で発生する２重のENCLOS ED BY文字は、単一のENCLOSED BY文字として処理されます。例えば、ENCLOSED BY '"'が指定されると、引用符は以下のように操作されます:

"The ""BIG"" boss"  -> The "BIG" boss
The "BIG" boss      -> The "BIG" boss
The ""BIG"" boss    -> The ""BIG"" boss

FIELDS ESCAPED BYは、特殊文字をどのように書き込んだり読み込んだりするかを制御します。 FIELDS ESCAPED BY文字が空でない場合、出力において次のような文字(文字列) のプリフィックスに使用されます:

FIELDS ESCAPED BY文字
FIELDS [OPTIONALLY] ENCLOSED BY文字
FIELDS TERMINATED BY値とLINES TERMINATED BY値の最初の文字
ASCII 0 (エスケープ文字の後に続いて実際に書かれる文字はASCII '0'で、'ゼロ値'バイトではありません)

FIELDS ESCAPED BY文字が空であれば、どの文字もエスケープされません。特に、フィールド値が上に示した文字を含んでいるならば、エスケープ文字に空を指定するのはあまり良い考えとは言えないでしょう。

入力において、FIELDS ESCAPED BY文字が空でない場合、この文字の出現は取り去られ、後続の文字はフィールド値の一部としてそのまま受け取られます。例外は、エスケープされた`0'や`N'です (例えば、エスケープ文字が`\'である時の\0や\N)。これらのシーケンスは、ASCII 0('ゼロ値'バイト) 、NULLとして処理されます。 code{NULL}操作の規則は下を参照して下さい。

`\'-escape syntaxに関するこれ以外の情報は、「6.1.1 文字列と数値をどのように書くか？」節参照。

フィールドとレコード操作オプションが確実に相互作用する事例:

LINES TERMINATED BYが空文字列でFIELDS TERMINATED BYが空でない場合、各レコードもまたFIELDS TERMINATED BYで終らせられます。
FIELDS TERMINATED BYとFIELDS ENCLOSED BY値が両方とも空('') の時、(区切られない)固定長行フォーマットが使用されます。固定長行フォーマットでは、フィールド間に区切り文字列が使用されません。その代わり、フィールド値は、フィールドの``表示''幅を使って書き込まれたり、読み込まれます。例えば、あるフィールドがINT(7)で定義されている場合、フィールドの値は7文字の桁を使って書き込まれます。入力においてフィールドは、７文字の読み込みにより得られます。固定長行フォーマットはまた、NULL値の操作に好んで用いられます;下を参照のこと。注意: マルチバイト文字セットを使用している場合は固定長フォーマットは働きません。

FIELDSとLINESオプションによるNULL値の多様な取扱い:

FIELDSとLINESの初期値のために、出力時にNULLは\Nとして書き込まれ、入力時に\NはNULLとして読み込まれます(当然のことながら、ESCAPED BY文字は`\'とします)。
FIELDS ENCLOSED BYが空で無い時、定数NULLのフィールド値はNULL値として読み込まれます(これは、文字列'NULL'として読み込まれるFIELD S ENCLOSED BY文字列で囲まれたNULLとは異なります)。
FIELDS ESCAPED BYが空の時、NULLはNULLとして書き込まれます。
固定長行フォーマット(FIELDS TERMINATED BYとFIELDS ENCLOSED BYがいずれも空の場合に起こります)において、NULLは、空白文字列として書き込まれます。これは、ファイル内では、NULL値と空白値の見分けがつかないということを示していることに注意して下さい。ファイルからデータを読み戻す時に両者を区別しなければならない場合、固定長行フォーマットは使用すべきではありません。

LOAD DATA INFILEでサポートされないケース:

固定長行(FIELDS TERMINATED BYとFIELDS ENCLOSED BYの両方が空)と BLOBフィールド。
あるセパレータを他と同じかもしくは他のプリフィックスとした場合、LOAD DATA INFILEは、正しい入力処理ができないでしょう。例えば、以下のFIELDS節は問題の原因となります:
```
FIELDS TERMINATED BY '"' ENCLOSED BY '"'
```
FIELDS ESCAPED BYが空で、フィールド値に、FIELDS ENCLOSED BY値や LINES TERMINATED BY値の後にFIELDS TERMINATED BY値がくるようなものを含む場合、フィールドや行の読み込みが早めに打ち切られてしまいます。これは、LOAD DATA INFILEが、フィールドやレコードの終了位置を正しく決められないことにより発生します。

次の例は、persondataテーブルの全てのフィールドを読み込みます:

mysql> LOAD DATA INFILE 'persondata.txt' INTO TABLE persondata;

フィールドリストが指定されていませんから、LOAD DATA INFILEは、入力レコードがテーブルのそれぞれのフィールドを含むものと想定します。 FIELDSとLINESの初期値が使用されます。

テーブルの一部のフィールドのみ読み込みたい場合、フィールドリストを指定します:

mysql> LOAD DATA INFILE 'persondata.txt'
    ->           INTO TABLE persondata (col1,col2,...);

テーブル内のフィールド順と入力ファイルのフィールド順が異なる場合にも、My SQLにテーブルのフィールドと入力フィールドの対応を教えるために、フィールドリストを指定しなければなりません。

入力レコードのフィールド数の方が少ない場合、入力フィールド値が与えられないフィールドは、初期値が設定されます。初期値の割当てについては、「6.5.3 CREATE TABLE 構文」節. で述べられています。

空のフィールド値は変換されます：

文字型の場合、フィールドの値は空文字にセットされます。
数値型の場合、フィールドの値は 0 にセットされます。
日付と時刻の型の場合、フィールドの値は ``zero'' の意味する値がセットされます。「6.2.2 日付と時間の型」節参照.

Note that these are the same values that result if you assign an empty string explicitly to a string, numeric, or date or time type explicitly in an INSERT or UPDATE statement.

TIMESTAMP フィールドは、フィールド値に NULL 値が指定されていた場合もしくは、フィールドリストが指定されている時に TIMESTAMP フィールドがそのリストから除外されていた場合 (最初のTIMESTAMPフィールドのみ)、現在時刻が設定されるだけです。

入力レコードのフィールド数の方が多い場合、余分なフィールドは無視され、警告の数が増やされます。

LOAD DATA INFILEは全ての入力を文字列と文字列とみなすことから、INSER TステートメントでできるようなENUMフィールドやSETフィールドへの数値の指定はできません。全てのENUM及びSET値は文字列として与えられなければいけません！

LOAD DATA INFILEクエリの終了時、クエリの情報を得るためにC API関数my sql_info()を使用することができます。情報の書式は以下に示すようなものです:

Records: 1  Deleted: 0  Skipped: 0  Warnings: 0

LOAD DATA INFILE が、入力レコードのフィールド数の過不足があった時にも警告を引き起こす事を除けば、INSERT ステートメント ( 「6.4.3 INSERT 構文」節参照. ) により値が挿入される時に警告が発生するのと同じ状況下で、警告が発生します。警告はどこにも保存されません；警告の数は全てうまくいった場合にだけ使用できます。もし警告を知りたい、その警告の理由を知りたいのなら、一つ方法があります。 SELECT ... INTO OUTFILE を使用して他のファイルに落とし、オリジナルのファイルと比べます。

パイプからの読み込みで LOAD DATA の必要があれば、次のトリックを使用できます:

mkfifo /mysql/db/x/x
chmod 666 /mysql/db/x/x
cat < /dev/tcp/10.1.1.12/4711 > /nt/mysql/db/x/x
mysql -e "LOAD DATA INFILE 'x' INTO TABLE x" x

If you are using a version of MySQL older than 3.23.25 you can only do the above with LOAD DATA LOCAL INFILE.

INSERTと比較したLOAD DATA INFILEの効率やLOAD DATA INFILEの高速化についてのより詳しい情報は、「5.2.9 INSERT クエリの速度」節参照を参照のこと。

6.4.10 `DO` Syntax

DO expression, [expression, ...]

Execute the expression but don't return any results. This is a shorthand of SELECT expression, expression, but has the advantage that it's slightly faster when you don't care about the result.

This is mainly useful with functions that has side effects, like RELEASE_LOCK.

6.5 Data Definition: `CREATE`, `DROP`, `ALTER`

6.5.1 `CREATE DATABASE` 構文

CREATE DATABASE [IF NOT EXISTS] db_name

CREATE DATABASE は与えられた名前のデータベースを作ります。データベースの名前として許される命名規則は、「6.1.2 データベース名、テーブル名、インデックス名、フィールド名、エイリアス名」節に依ります。もし、データベースがすでに存在しているにもかかわらず IF NOT EXISTS を指定していなかったら、エラーが発生します。

MySQLにおけるデータベースは、データベース内のテーブルに相当するファイルを含むディレクトリとして実装されます。初期作成後はデータベース内にテーブルは存在せず、CREATE DATABASEステートメントは、MySQLデータディレクトリ下にディレクトリを作成するだけです。

mysqladminでもデータベースを作成することができます。「4.8 MySQL Client-Side Scripts and Utilities」節参照.

6.5.2 `DROP DATABASE` 構文

DROP DATABASE [IF EXISTS] db_name

DROP DATABASEは、データベース内の全てのテーブルと共にデータベースを破棄します。シンボリックリンクされた DROP DATABASE を行なうと、リンクとオリジナルデータベースの両方が削除されます。 このコマンドの使用には万全の注意を払って下さい！

DROP DATABASEは、データベースディレクトリから削除されたファイルの数を返します。それぞれのテーブルは`.MYD'ファイル／`.MYI'ファイル／`.frm' ファイルに相当することから、通常この値はテーブルの３倍の数となります。

DROP DATABASE コマンドは与えられたデータベースディレクトリから、次の拡張子のすべてのファイルを削除します:

Ext	Ext	Ext	Ext
.BAK	.DAT	.HSH	.ISD
.ISM	.ISM	.MRG	.MYD
.MYI	.db	.frm

2桁の数値のすべてのサブディレクトリ(RAID ディレクトリ)も削除されます。

MySQL 3.22以降では、データベースが存在しないことに起因するエラーを防ぐために、キーワード IF EXISTS を使用することができます。

mysqladminでもデータベースを破棄することができます。「4.8 MySQL Client-Side Scripts and Utilities」節参照.

6.5.3 `CREATE TABLE` 構文

CREATE [TEMPORARY] TABLE [IF NOT EXISTS] tbl_name [(create_definition,...)]
[table_options] [select_statement]

or

CREATE [TEMPORARY] TABLE [IF NOT EXISTS] tbl_name LIKE old_table_name;

create_definition:
  col_name type [NOT NULL | NULL] [DEFAULT default_value] [AUTO_INCREMENT]
            [PRIMARY KEY] [reference_definition]
  or    PRIMARY KEY (index_col_name,...)
  or    KEY [index_name] (index_col_name,...)
  or    INDEX [index_name] (index_col_name,...)
  or    UNIQUE [INDEX] [index_name] (index_col_name,...)
  or    FULLTEXT [INDEX] [index_name] (index_col_name,...)
  or    [CONSTRAINT symbol] FOREIGN KEY [index_name] (index_col_name,...)
            [reference_definition]
  or    CHECK (expr)

type:
        TINYINT[(length)] [UNSIGNED] [ZEROFILL]
  or    SMALLINT[(length)] [UNSIGNED] [ZEROFILL]
  or    MEDIUMINT[(length)] [UNSIGNED] [ZEROFILL]
  or    INT[(length)] [UNSIGNED] [ZEROFILL]
  or    INTEGER[(length)] [UNSIGNED] [ZEROFILL]
  or    BIGINT[(length)] [UNSIGNED] [ZEROFILL]
  or    REAL[(length,decimals)] [UNSIGNED] [ZEROFILL]
  or    DOUBLE[(length,decimals)] [UNSIGNED] [ZEROFILL]
  or    FLOAT[(length,decimals)] [UNSIGNED] [ZEROFILL]
  or    DECIMAL(length,decimals) [UNSIGNED] [ZEROFILL]
  or    NUMERIC(length,decimals) [UNSIGNED] [ZEROFILL]
  or    CHAR(length) [BINARY]
  or    VARCHAR(length) [BINARY]
  or    DATE
  or    TIME
  or    TIMESTAMP
  or    DATETIME
  or    TINYBLOB
  or    BLOB
  or    MEDIUMBLOB
  or    LONGBLOB
  or    TINYTEXT
  or    TEXT
  or    MEDIUMTEXT
  or    LONGTEXT
  or    ENUM(value1,value2,value3,...)
  or    SET(value1,value2,value3,...)

index_col_name:
        col_name [(length)]

reference_definition:
        REFERENCES tbl_name [(index_col_name,...)]
                   [MATCH FULL | MATCH PARTIAL]
                   [ON DELETE reference_option]
                   [ON UPDATE reference_option]

reference_option:
        RESTRICT | CASCADE | SET NULL | NO ACTION | SET DEFAULT

table_options:
	TYPE = {BDB | HEAP | ISAM | InnoDB | MERGE | MRG_MYISAM | MYISAM }
or	AUTO_INCREMENT = #
or	AVG_ROW_LENGTH = #
or	CHECKSUM = {0 | 1}
or	COMMENT = "string"
or	MAX_ROWS = #
or	MIN_ROWS = #
or	PACK_KEYS = {0 | 1 | DEFAULT}
or	PASSWORD = "string"
or	DELAY_KEY_WRITE = {0 | 1}
or      ROW_FORMAT= { default | dynamic | fixed | compressed }
or	RAID_TYPE= {1 | STRIPED | RAID0 } RAID_CHUNKS=#  RAID_CHUNKSIZE=#
or	UNION = (table_name,[table_name...])
or	INSERT_METHOD= {NO | FIRST | LAST }
or      DATA DIRECTORY="absolute path to directory"
or      INDEX DIRECTORY="absolute path to directory"

select_statement:
	[IGNORE | REPLACE] SELECT ...  (Some legal select statement)

CREATE TABLEはカレントデータベースに、与えられた名前のテーブルを作成します。テーブルの名前として許される命名規則は、「6.1.2 データベース名、テーブル名、インデックス名、フィールド名、エイリアス名」節参照に依ります。カレントデータベースが無い場合や、テーブルが既に存在している場合はエラーが発生します。

MySQL バージョン 3.22 以降ではテーブル名は db_name.tbl_name という形で与える事もできます。これはカレントデータベースがあるかどうかにに関係なく動作します。

MySQL バージョン 3.23 からは、テーブル作成時に TEMPORARY キーワードを使用することができます。一時テーブルの名前はそれぞれの接続内に制限されます。一時テーブルは、もし、コネクションが落ちた場合、自動で消去されます。これは、二つの違う接続で、同じ名前の一時テーブルを衝突することなく、使用できるという事です。さらには、既に存在するテーブルと同名であっても、一時テーブルは使用できます。 (一時テーブルが削除されるまで、実在するテーブルは隠されます) From MySQL 4.0.2 one must have the CREATE TEMPORARY TABLES privilege to be able to create temporary tables.

MySQL バージョン 3.23 以降では、 IF NOT EXISTS キーワードを使用できます。これは、もしテーブルが既に存在していた場合、エラーを発生させません。テーブルの構造が一意かどうかまでは検査しないことに注意。

In MySQL 4.1 you can use LIKE to create a table based on a table definition in another table. In MySQL 4.1 you can also specify the type for a generated column:

CREATE TABLE foo (a tinyint not null) SELECT b+1 AS 'a' FROM bar;

それぞれのテーブルは、データベースディレクトリにおける以下の複数のファイルで表されます。これは MyISAM 型のテーブル場合：

File	Purpose
`tbl_name.frm`	Table definition (form) file
`tbl_name.MYD`	Datafile
`tbl_name.MYI`	Index file

フィールドに対する種々の型属性の詳細は、「6.2 フィールド型」節を参照のこと。

NULLもNOT NULLも指定されなかった場合、フィールドはNULLが指定されたものとして扱われます。
整数型のフィールドには付加属性AUTO_INCREMENTも指定することができます。 AUTO_INCREMENTのフィールドに値NULL又は0を挿入した場合、フィールドにはvalue+1の値がセットされます。valueは、そのテーブル内の当該フィールドにおける現在の最大値です。 AUTO_INCREMENT は 1 からはじまります. 「8.4.3.130 mysql_insert_id()」節参照. 削除したレコードが、AUTO_INCREMENTフィールドの最大値を含んでいた場合、その値は、ISAM と BDB テーブルでは、次に再利用されますが、 MyISAM と InnoDB テーブルでは再利用されません。また、テーブル内の全てのレコードを DELETE FROM table_name (WHERE節無しで) を AUTOCOMMIT モードで使用して削除した場合は、すべてのテーブル型で始めから採番し直します。注意: 1つのテーブルには1つしかAUTO_INCREMENTフィールドを指定できません。また、インデックスを指定する必要があります。 MySQL 3.23 は auto_increment フィールドが正の数を持っている場合にだけ、正しく動作します。負の数の挿入はとても大きな正の数の挿入とみなされます。これは、数値が正から負への 'wrap' over する時の精度の問題を回避するためと、アクシデント的に 0 を含む auto_increment フィールドを得ることがないことを確実にするために、行なわれます。 In MyISAM and BDB tables you can specify AUTO_INCREMENT secondary column in a multi-column key. 「3.5.9 Using AUTO_INCREMENT」節参照. MySQL をいくつかの ODBC アプリケーションと互換にするために、次のクエリで最後に挿入されたレコードを見つけることができます:
```
SELECT * FROM tbl_name WHERE auto_col IS NULL
```
CREATE TABLE automatically commits the current InnoDB transaction if MySQL binary logging is used.
TIMESTAMPフィールドにおけるNULL値は、他のフィールド属性と違った扱われ方をします。定数NULLをTIMESTAMPフィールドに格納することはできません。NULL値の指定は現在時刻をセットすることを意味します。 TIMESTAMPフィールドがこのように振舞うので、通常はNULL属性や NOT NULL属性は適用できません。それらを指定しても無視されます。一方、MySQLクライアントからは、より安易にTIMESTAMPフィールドを利用でき、サーバもTIMESTAMPフィールドへのNULLの適用を報告しますが、TIMESTAMPフィールドは実際にはNULL値を保存することはありません。 code{DESCRIBE tbl_name}を使用して、テーブル定義文を取得することにより、この現象を確認することができます。 TIMESTAMPフィールドに0を指定することは、NULLを指定することと等しくないことに注意してください。なぜなら、0はTIMESTAMPの値として不正であるからです。
A DEFAULT value has to be a constant, it cannot be a function or an expression. フィールドに対して DEFAULT 値が指定されない場合は MySQL が自動的にそれを割り当てます。フィールドが NULL を値として取り得る場合は、デフォルト値は NULL です。フィールドが NOT NULL として宣言された場合は、デフォルト値はフィールド型に依存します:
- AUTO_INCREMENT 定義された以外の数値型のフィールドに対しては、初期値は0となります。 AUTO_INCREMENTフィールドでは、デフォルト値は次のシーケンス番号になります。
- TIMESTAMP 型以外の日付型と時刻型のフィールドに対しては、初期値はその型において適切な``ゼロ''値となります。例外: フィールドがそのテーブル内で最初のTIMESTAMPフィールドである場合、初期値は現在時刻になります。「6.2.2 日付と時間の型」節参照.
- ENUM 以外の文字列型のフィールドに対しては、初期値は空文字列となります。 ENUM では、デフォルト値は最初の列挙の値です。
Default values must be constants. This means, for example, that you cannot set the default for a date column to be the value of a function such as NOW() or CURRENT_DATE.
KEYは、INDEXの同義語です。
MySQLでは、UNIQUEキーは固有値しか持つことができません。既に存在するレコードとキーの値が重複するレコードを挿入しようとした場合、エラーが発生します。
PRIMARY KEY はユニーク KEY で、すべてのキーフィールドは NOT NULL として定義されなければならないという特別な制限を伴います。 MySQL ではキーは PRIMARY と名付けられます。テーブルは PRIMARY KEY を一つだけ持つことができます。PRIMARY KEY を持たない場合に、アプリケーションがテーブル内の PRIMARY KEY を尋ねると、 MySQL は PRIMARY KEY として、NULL フィールドを持たない最初の UNIQUE キーを返します。
PRIMARY KEYは複数フィールドインデックスとできます。しかしながら、1つのフィールド定義内ではPRIMARY KEY属性を用いて複合インデックスを定義することができませんので、フィールド定義内における指定は、プライマリ・キーが単独フィールドの場合のみとして下さい。複合フィールドの場合は、 PRIMARY KEY(index_col_name,...)文を使用しなければなりません。
PRIMARY や UNIQUE キーが１つのフィールドだけからなり、その型が整数の場合、それを _rowid としても参照することができます (バージョン 3.23.11 での新機能)。
インデックスに名前を割り当てない場合、一意な名前を付けるために、 index_col_name 内の最初のフィールド名に(_2, _3, ...)のようなサフィックスを付加したものが割り当てられます。テーブルが使用しているインデックス名は、 SHOW INDEX FROM tbl_nameにより確認することができます。「4.5.6.1 Retrieving information about Database, Tables, Columns, and Indexes」節参照.
MyISAM テーブルのみが、NULL 値をもつフィールドに対してインデックスを持つことが出来ます。その他のテーブル型の場合、フィールドを NOT NULL で定義しなくてはなりません。
col_name(length)文を共に指定することで、CHARフィールド又は VARCHARフィールドの一部分だけをインデックスとして定義できます。これによりインデックスファイルを適度に小さくすることができます。「5.4.4 Column Indexes」節参照.
MyISAM テーブル型のみが、 BLOB と TEXT フィールド上にインデックスを持つことが出来ます。 BLOB と TEXT フィールドにインデックスを張る場合、常に、インデックスの長さを指定しなくてはなりません：
```
CREATE TABLE test (blob_col BLOB, INDEX(blob_col(10)));
```
TEXTフィールドやBLOBフィールドで ORDER BY や GROUP BY を使用すると、最初のmax_sort_lengthバイトだけが使用されます。「6.2.3.2 BLOB と TEXT 型」節参照.
MySQL バージョン 3.23.23 以降では、特殊な FULLTEXT インデックスも生成できます。それらは全文検索に使用されます。MyISAM テーブル型だけが FULLTEXT インデックスをサポートします。それらは CHAR, VARCHAR, TEXT フィールドからだけ生成できます。インデックスは常にフィールド全体に起こります。部分インデックスはサポートされません。オペレーションの詳細は「6.8 MySQL Full-text Search」節を見てください。
In MySQL Version 3.23.44 or later, InnoDB tables support checking of foreign key constraints. 「7.5 InnoDB テーブル (3.23.6以上)」節参照. Note that the FOREIGN KEY syntax in InnoDB is more restricted than the syntax presented above. InnoDB does not allow index_name to be specified, and the columns of the referenced table always have to be explicitly named. Starting from 4.0.8 InnoDB supports both ON DELETE and ON UPDATE actions on foreign keys. See the InnoDB manual section for the precise syntax. 「7.5 InnoDB テーブル (3.23.6以上)」節参照. For other table types, MySQL Server does parse the FOREIGN KEY, CHECK, and REFERENCES syntax in CREATE TABLE commands, but without further action being taken. 「1.7.4.5 外部キー」節参照.
全てのNULLフィールドは、1ビット余計に消費し、直近のバイトに丸められます。

レコードの最大長は、以下のようにして求められます:

レコードの長さ = 1
             + (フィールドの長さの合計)
             + (NULLフィールドの数 + 7)/8
             + (可変長フィールドの数)

table_options と SELECT オプションは、 MySQL 3.23 以上でのみ実装されます。テーブル型は：

Table type	Description
BDB または BerkeleyDB	トランザクションセーフなテーブル「7.6 `BDB` or `BerkeleyDB` Tables」節参照.
HEAP	このテーブルのデータは、メモリー内にのみ蓄えられる「7.4 `HEAP` Tables (3.23.0以上)」節参照.
ISAM	オリジナルのテーブル「7.3 `ISAM` Tables」節参照.
InnoDB	レコードロッキングを持ったトランザクション安全テーブル「7.5 `InnoDB` テーブル (3.23.6以上)」節参照.
MERGE	一つのテーブルとして使用される MyISAM テーブルの集まり「7.2 `MERGE` Tables (3.23.25以上)」節参照.
MRG_MyISAM	An alias for MERGE tables
MyISAM	ISAM にかわる新しいバイナリ互換のテーブル。「7.1 `MyISAM` テーブル (3.23.0以上)」節参照.

「7 MySQL テーブル型」節参照. テーブル型が指定され、特定の型が有効でない場合、MySQL は指定されたものに近いテーブル型を選択します。例えば、TYPE=BDB が指定されて、 MySQL のディストリビューションが BDB テーブルをサポートしない場合、代わりにテーブルは MyISAM として生成されます。その他のテーブルオプションを使って、テーブルの振る舞いを最適化します。たいていの場合は、オプションを明示する必要がありません。明示的に指定されなかった場合、オプションはすべてのテーブル型に作用します。

Option	Description
`AUTO_INCREMENT`	あなたがこのテーブルにセットしたい、次の `AUTO_INCREMENT` 値
`AVG_ROW_LENGTH`	テーブルに含まれるレコードの長さのおおよその平均値。可変長のレコードを持つ大きなテーブルに対してのみ、これをセットします。
`CHECKSUM`	MySQL に全てのレコードをチェックさせたい場合、これを 1 にセットします。 (これは更新を遅くさせますが、不整合の生じたテーブルを見つけ出しやすくなります) (MyISAM)
`COMMENT`	テーブルの、60文字コメント
`MAX_ROWS`	あなたがテーブルに保存したいと考えている最大レコード数。
`MIN_ROWS`	あなたがテーブルに保存したいと考えている最低レコード数
`PACK_KEYS`	より小さいインデックスにしたいなら、これを 1 にします。これは更新を遅くしますが、読み出しは速くなります (MyISAM, ISAM). Setting this to 0 will disable all packing of keys. Setting this to `DEFAULT` (MySQL 4.0) will tell the storage engine to only pack long `CHAR`/`VARCHAR` columns.
`PASSWORD`	`.frm` ファイルをパスワード付きで暗号化。このオプションは、標準の MySQL バージョンではなにも行いません。
`DELAY_KEY_WRITE`	テーブルがクローズされるまでキーテーブルの更新を送らせたい場合、1に設定します(MyISAM)。
`ROW_FORMAT`	レコードがどのように格納されるかを定義します。現在 DYNAMIC と STATIC オプションが MyISAM テーブルのために使用できるだけです。

MyISAM テーブルを使用するならば、MySQL は max_rows * avg_row_length の値を、テーブルがどのくらい大きくなるかの推定に使用します。もし、上記のオプションをなにも指定しなかった場合、テーブルの最大サイズは 4G になります。(か、あなたの OS が 2G しかサポートしていなければ 2G まで) この理由は、大きなファイルを本当に必要としない場合は、インデックスをより小さく、より速くするため、ポインタサイズを小さく保持するためです。 PACK_KEYS を使用しない場合、デフォルトは文字列だけをパックし、数値はパックしません。PACK_KEYS=1 を使用するとさらに数値もパックされます。バイナリ数値キーをパックする時、MySQL はプレフィックス圧縮を使用します。これは、同じ数値を多く持つ場合にだけこの大きな恩恵を得るということを意味します。プレフィックス圧縮は、前のキーの何バイトが次のキーと同じであるかを示すための余計な1バイトがすべてのキーに必要となることを意味します(注意: レコードへのポインタは、圧縮の向上のため high-byte-first-order でキーの直後に格納されます)。これは、2つのレコードが同じキー多く持つ場合、後のすべての'同じ'キーは通常2バイト(レコードへのポインタを含む)だけを必要とするということです。これを、通常のケースと比較してみてください。通常のケースは、後のキーは'キーの格納サイズ' + ポインタサイズ(通常4)を必要とします。一方、すべてのキーが全く異なっていると、キーが NULL 値を持つことができるキーではない場合では、キー毎に1バイトを消費します(この場合、パックされたキーの長さは、キーが NULL の時にマークのために使用されるのと同じバイト数で格納されます)。

もし CREATE ステートメントの後に SELECT を指定するならば、 MySQL は、SELECT で返ってくる全ての項目を収めるために、新しいフィールドを作成します。例えば：
```
mysql> CREATE TABLE test (a INT NOT NULL AUTO_INCREMENT,
    ->        PRIMARY KEY (a), KEY(b))
    ->        TYPE=MyISAM SELECT b,c FROM test2;
```
これは 3つのフィールド a, b, c を MyISAM テーブルに作成します。 SELECT ステートメントからのフィールドがテーブルの右側に追加され、上書きされないことに注意してください。次の例を見てください:
```
mysql> SELECT * FROM foo;
+---+
| n |
+---+
| 1 |
+---+

mysql> CREATE TABLE bar (m INT) SELECT n FROM foo;
Query OK, 1 row affected (0.02 sec)
Records: 1  Duplicates: 0  Warnings: 0

mysql> SELECT * FROM bar;
+------+---+
| m    | n |
+------+---+
| NULL | 1 |
+------+---+
1 row in set (0.00 sec)
```
テーブル foo の各レコードについて、foo からの値と新しいフィールドのデフォルト値を伴って bar のレコードが挿入されます。 CREATE TABLE ... SELECT will not automatically create any indexes for you. This is done intentionally to make the command as flexible as possible. If you want to have indexes in the created table, you should specify these before the SELECT statement:
```
mysql> CREATE TABLE bar (UNIQUE (n)) SELECT n FROM foo;
```
もしデータをテーブルにコピーしている最中にエラーが起きたなら、このテーブルは自動的に消去されることに注意してください。更新ログ／バイナリログはオリジナルテーブルを再生成するために使用できます。 MySQL は CREATE TABLE .... SELECT 中に並行しての挿入を許しません。
RAID_TYPE オプションは、大規模ファイルをサポートしていない OS 上の 2G/4Gの制限を破る手助けをします。Note that this option is not recommended for filesystem that supports big files! また、RAID ディレクトリを別の物理ディスクに置くことにより、IO ボトルネックからさらに速度を得ることができます。RAID_TYPE は、MySQL を --with-raid でコンフィグすれば、どんな OS 上でも働きます。現在、RAID_TYPE は STRIPED だけが許されています(1 と RAID0 はこれの別名です)。 RAID_TYPE=STRIPED を MyISAM テーブルに指定すると、 MyISAM はデータベースディレクトリ中に 00, 01, 02 という名前の RAID_CHUNKS サブディレクトリを生成します。これらのディレクトリのそれぞれに、MyISAM は table_name.MYD を生成します。データファイルにデータが書き込まれる時、RAID ハンドラは最初の RAID_CHUNKSIZE *1024 バイトを最初のファイルに、次の RAID_CHUNKSIZE *1024 バイトを次のファイルにマップします。
UNION は同じテーブルの集まりを一つとして使用したい時に使用されます。これは MERGE テーブルでだけ動作します。「7.2 MERGE Tables (3.23.25以上)」節参照. 今のところ、MERGE テーブルをマップするテーブル上に SELECT, UPDATE, DELETE 権限を持つことが必要です。マップされたすべてのテーブルは MERGE テーブルとして、同じデータベース内にある必要があります。
If you want to insert data in a MERGE table, you have to specify with INSERT_METHOD into with table the row should be inserted. 「7.2 MERGE Tables (3.23.25以上)」節参照. This option was introduced in MySQL 4.0.0.
生成されたテーブルでは、PRIMARY キーは最初に置かれ、次にすべての UNIQUE キー、それから通常のキーが続きます。これは MySQL オプティマイザを助け、どのキーを使用するかの優先度付けを行ない、重なった UNIQUE キーをさらにすばやく検出します。
DATA DIRECTORY="directory" または INDEX DIRECTORY="directory" を使用することで、the storage engine がテーブルとインデックスファイルを置くべき場所を指定できます。--skip-symlink オプションを使用しない時、これは MySQL 4.0 で MyISAM テーブルでだけ動作します。「5.6.1.2 Using Symbolic Links for Tables」節参照.

6.5.3.1 暗黙のフィールド定義変更

いくつかのケースにおいてMySQLは、CREATE TABLEステートメントで与えられたフィールド定義を暗黙の内に変更します (これは ALTER TABLE で起きるかもしれません)

VARCHAR columns with a length less than four are changed to CHAR.
テーブル内にいくつかの可変長フィールドがある場合、結果的にレコード全体が可変長となります。その結果、テーブルがいくつかの可変長フィールド(VARCHAR、TEXT及び BLOB)を持つならば、3文字より大きいフィールド長の全てのCHARフィールドは、 VARCHARフィールドに変更されます。このことは、フィールドの使用方法には影響しません。 MySQLでは、VARCHARは文字列を格納するための1つの手段に過ぎません。 MySQLは、スペース埋めのコンバージョンを行いますし、テーブル操作もより速く行います。「7 MySQL テーブル型」節参照.
TIMESTAMPフィールドの表示サイズは、2～14の範囲の偶数でなければなりません。表示サイズを0や14より大きく指定した場合、サイズは14に強制されます。1から13の範囲の奇数の場合、大きい方の偶数値に強制されます。
TIMESTAMP フィールドには NULL を代入できません； NULL は現在の日時をセットします。 NULL and NOT NULL 属性は通常の方法では適用されず、それらを与えた場合は無視されます。 DESCRIBE tbl_name は常に TIMESTAMP フィールドに NULL 値が割り当てられた事を告げます。
MySQL は他の SQL データベースの使用している型を MySQL 型にマップします。「6.2.5 他のデータベースエンジンのフィールド型の使用」節参照.

もし MySQL がフィールドの型をあなたが指定したものと違うものにしたかどうかを知りたい場合、テーブルの作成、alter 後に、 DESCRIBE tbl_name 構文を発行します。

myisampackを使用してテーブルを圧縮した場合、別のフィールド定義変更がある程度起こることがあります。「7.1.2.3 圧縮テーブルの特徴」節参照.

6.5.4 `ALTER TABLE` 構文

ALTER [IGNORE] TABLE tbl_name alter_spec [, alter_spec ...]

alter_specification:
        ADD [COLUMN] create_definition [FIRST | AFTER column_name ]
  or    ADD [COLUMN] (create_definition, create_definition,...)
  or    ADD INDEX [index_name] (index_col_name,...)
  or    ADD PRIMARY KEY (index_col_name,...)
  or    ADD UNIQUE [index_name] (index_col_name,...)
  or    ADD FULLTEXT [index_name] (index_col_name,...)
  or	ADD [CONSTRAINT symbol] FOREIGN KEY [index_name] (index_col_name,...)
            [reference_definition]
  or    ALTER [COLUMN] col_name {SET DEFAULT literal | DROP DEFAULT}
  or    CHANGE [COLUMN] old_col_name create_definition
               [FIRST | AFTER column_name]
  or    MODIFY [COLUMN] create_definition [FIRST | AFTER column_name]
  or    DROP [COLUMN] col_name
  or    DROP PRIMARY KEY
  or    DROP INDEX index_name
  or    DISABLE KEYS
  or    ENABLE KEYS
  or    RENAME [TO] new_tbl_name
  or    ORDER BY col
  or    table_options

ALTER TABLEは、既存のテーブルの構造変更を可能にします。例えば、フィールドの追加や削除、インデックスの作成や破棄、既存のフィールド属性の変更、及びフィールドやテーブルそのものの名前の変更です。また、テーブルのコメントやテーブルの型式を変更することも可能です。「6.5.3 CREATE TABLE 構文」節参照.

もし ALTER TABLE でフィールド定義を変えても DESCRIBE tbl_name がフィールドを変更していないと示すなら、これは MySQL が「6.5.3.1 暗黙のフィールド定義変更」節. に述べている理由の一つで変更していない可能性があります。例えば、 VARCHAR フィールドを CHAR にしようとすると, MySQL はそのテーブルに他の可変長のフィールドがあるかぎり、 VARCHAR のままにしようとします。

ALTER TABLEはオリジナルのテーブルの一時的なコピーを作成することにより動作します。コピーへの変更作業が完了すると、オリジナルのテーブルは削除され新しく作られた方の名前が変更されます。これは全ての変更が自動的に新しいテーブルに対して実施されることにより、誤った変更無しに完了します。 ALTER TABLEが実行されている間、オリジナルのテーブルは他のクライアントから読みだしが可能です。このテーブルへの更新や書き込みは、新しいテーブルが準備完了となるまで遅らされます。

注意: ALTER TABLE に RENAME 以外のオプションを使用する場合、 MySQL は常に一時テーブルを生成します。データが厳密にコピーする必要がないとしてもです(フィールドの名前を変更する時など)。 We plan to fix this in the future, but as one doesn't normally do ALTER TABLE that often this isn't that high on our TODO. For MyISAM tables, you can speed up the index recreation part (which is the slowest part of the recreation process) by setting the myisam_sort_buffer_size variable to a high value.

ALTER TABLEを使うには、そのテーブルに ALTER, INSERT, CREATE 権限が必要です。
IGNOREはANSI SQL92に対するMySQLの拡張です。これは、新しいテーブルのユニークキーで重複があった場合の動作を制御します。 IGNOREが指定されない場合、コピーは異常終了し、ロールバックされます。 IGNOREが指定された場合、ユニークキーの重複があったレコードに対し、最初のレコードだけを使用し、他は削除されます。
1つのALTER TABLEステートメントの中で、ADD、ALTER、 DROP、それからCHANGE節の複合的な発行が可能です。これは、ALTER TABLEステートメント毎に1つだけしかこれらの節を許さないANSI SQL92に対するMySQLの拡張です。
CHANGE col_name、DROP col_name及びDROP INDEXはANSI SQL92に対するMySQLの拡張です。
MODIFY は Oracle の ALTER TABLE 拡張です。
オプション語COLUMNは蛇足であり、記述を省くことが可能です。
他のオプション無しでALTER TABLE tbl_name RENAME TO new_nameを使用すると、 MySQLはtbl_nameに一致するテーブルの名前を単純に変更します。テンポラリテーブルの作成は必要としません。「6.5.5 RENAME TABLE 構文」節参照.
create_definitionは、CREATE TABLEにおけるADDやCHANGE と同じ構文を使用します。「6.5.3 CREATE TABLE 構文」節参照.
CHANGE old_col_name create_definition節を使用することによりフィールドの名前を変更することができます。このようなことを行うためには、フィールドの旧名称と新名称、それからそのフィールドの現在の型を指定する必要があります。例えば、あるINTEGERフィールドをaからbに変更する場合、以下のように実行することができます:
```
mysql> ALTER TABLE t1 CHANGE a b INTEGER;
```
もしフィールドの名前を変えることなく、型だけを変更したい場合であっても、この CHANGE 構文は、たとえ同じ名前であっても、２つの名前を指定するよう要求します。例:
```
mysql> ALTER TABLE t1 CHANGE b b BIGINT NOT NULL;
```
しかし MySQL バージョン 3.22.16a からは, MODIFY を使用して、名称変更をすることなくフィールドの型を変更することができます。
```
mysql> ALTER TABLE t1 MODIFY b BIGINT NOT NULL;
```
CHANGE や MODIFY を使用して、フィールドの一部にインデックスが存在するようなフィールドを短くしようとしても(例えば VARCHAR フィールドの最初の10文字上ににインデックスがある場合)、インデックスされた文字数よりもフィールドを短くすることはできません。
CHANGE や MODIFY を用いてフィールドの型を変更する場合、 MySQLは可能な限り新しい型にデータをコンバートしようと試みます。
MySQL バージョン 3.22以降では、 FIRST又はADD ... AFTER col_nameを使用して、テーブルのレコード内の指定した位置に、フィールドを追加することができます。デフォルトでは、フィールドは(そのレコードの)最後に追加されます。 From MySQL Version 4.0.1, you can also use the FIRST and AFTER keywords in CHANGE or MODIFY.
ALTER COLUMNは、フィールドの新たな初期値を指定したり、フィールドの古い初期値を削除したりします。古い初期値が削除され、フィールドがNULLを許す場合、新たな初期値は NULLとなります。 NULLが許されない場合、「6.5.3 CREATE TABLE 構文」節で説明されている通り、MySQL は初期値を割り当てます。「6.5.3 CREATE TABLE 構文」節.
DROP INDEXは、インデックスを削除します。これはANSI SQL92に対する MySQL の拡張です。「6.5.8 DROP INDEX 構文」節参照.
フィールドがテーブルから削除されると、そのフィールドが含まれているインデックスからもそのフィールドが削除されます。インデックスを構成する全てのフィールドが削除されると、そのインデックスも削除されます。
テーブルが一つのフィールドだけを含む場合、フィールドは破棄できません。テーブルを削除するつもりなら、DROP TABLE を代わりに使用してください。
DROP PRIMARY KEYは、プライマリ・インデックスを削除します。もしプライマリインデックスが存在しなければ、そのテーブルの最初のUNIQUEインデックスが削除されます。 (MySQLは、明示的にPRIMARY KEYが指定されなければ最初のUNIQU EキーをPRIMARY KEYとして扱います。) If you add a UNIQUE INDEX or PRIMARY KEY to a table, this is stored before any not UNIQUE index so that MySQL can detect duplicate keys as early as possible.
ORDER BY は指定した順のレコードで新しいテーブルを生成することができます。注意: 挿入と削除の後にはこの順序は保持されません。テーブルを、後で order をしたいフィールドの順にしておくと MySQL のソートがより簡単になる場合があります。このオプションは、主に一定の順でレコードをクエリするつもりであることを知っているときに、主に有用です; テーブルに大きな変更をした後にこのオプションを使用することで、より高い性能を得ることができるdしょう。
ALTER TABLE を MyISAM テーブルに使用する場合、すべての非ユニークインデックスは(REPAIR のような)別のバッチで生成されます。これは多くのインデックスがある場合、ALTER TABLE をより速くします。
Since MySQL 4.0 the above feature can be activated explicitly. ALTER TABLE ... DISABLE KEYS makes MySQL to stop updating non-unique indexes for MyISAM table. ALTER TABLE ... ENABLE KEYS then should be used to recreate missing indexes. As MySQL does it with special algorithm which is much faster then inserting keys one by one, disabling keys could give a considerable speedup on bulk inserts.
C API関数mysql_info()により、どれだけのレコードがコピーされたか、(I GNOREが指定されている時は)どれだけのレコードがユニークキーの重複により削除されたかを調べることができます。
FOREIGN KEY、CHECK及びREFERENCES節は、 ADD CONSTRAINT FOREIGN KEY (...) REFERENCES ... (...) をサポートする InnoDB 型以外のテーブルでは実際には何もしません。 Note that InnoDB does not allow an index_name to be specified. 「7.5 InnoDB テーブル (3.23.6以上)」節参照. 他のテーブルに対するこれらの構文は、互換性のためだけに用意されており、他のSQLサーバからのコードの移植を容易にしたり、参照情報と共にテーブルを作成するようなアプリケーションを動作させることを目的としています。「1.7.4 MySQL と ANSI SQL92 との違い」節参照.

以下は、ALTER TABLEの使用例を表す例です。次に示すように作成されたテーブルt1から始めます:

mysql> CREATE TABLE t1 (a INTEGER,b CHAR(10));

テーブルt1の名前をt2に変更するには:

mysql> ALTER TABLE t1 RENAME t2;

フィールド aを INTEGER から TINYINT NOT NULL に (名前は同じままで)変更し、 b を CHAR(10) から CHAR(20) に変更しつつ、名前を b から cに変更するには:

mysql> ALTER TABLE t2 MODIFY a TINYINT NOT NULL, CHANGE b c CHAR(20);

TIMESTAMPを追加し、名前をdとするには:

mysql> ALTER TABLE t2 ADD d TIMESTAMP;

フィールドdにインデックスを追加し、フィールドaをプライマリ・キーとするには:

mysql> ALTER TABLE t2 ADD INDEX (d), ADD PRIMARY KEY (a);

フィールドcを削除するには:

mysql> ALTER TABLE t2 DROP COLUMN c;

To add a new AUTO_INCREMENT integer column named c:

mysql> ALTER TABLE t2 ADD c INT UNSIGNED NOT NULL AUTO_INCREMENT,
    ->       ADD INDEX (c);

ここで我々が c をインデックス指定したのは、 AUTO_INCREMENT フィールドはインデックスであるべきだからで、 c を NOT NULL 指定しているのはインデックスフィールドは NULL にできないからです。

AUTO_INCREMENT フィールドを追加した場合、フィールドの値は自動的にシーケンス番号で埋められます。最初のシーケンス番号は、ALTER TABLE 前に SET INSERT_ID=# を実行するか、または AUTO_INCREMENT = # テーブルオプションを使用することで設定できます。「5.5.6 SET 構文」節参照.

MyISAM テーブルでは、AUTO_INCREMENT フィールドを変更しない場合、シーケンス番号は影響を受けません。AUTO_INCREMENT フィールドを破棄し、それから別の AUTO_INCREMENT フィールドを追加した場合、番号は再度 1 から始まります。

「A.6.1 Problems with ALTER TABLE.」節参照.

6.5.5 `RENAME TABLE` 構文

RENAME TABLE tbl_name TO new_tbl_name[, tbl_name2 TO new_tbl_name2,...]

リネームは自動的に行なわれます。これは、他のスレッドはリネームが動作中はテーブルのどこにもアクセスできないことを意味します。空のテーブルでテーブルを置き換えることが可能です:

CREATE TABLE new_table (...);
RENAME TABLE old_table TO backup_table, new_table TO old_table;

リネームは左から右に行なわれます。２つのテーブルの名前を交換したい場合には、次のようにする必要があることを意味します:

RENAME TABLE old_table    TO backup_table,
             new_table    TO old_table,
             backup_table TO new_table;

２つのデータベースが同じディスク上にあれば、あるデータベースから他のデータベースにリネームすることも可能です:

RENAME TABLE current_database.table_name TO other_database.table_name;

RENAME 実行時には、ロックされたテーブルや有効なトランザクションを持つことはできません。元のテーブルで ALTER と DROP 権限を、新しいテーブルで CREATE と INSERT 権限を持つことも必要です。

MySQL が複数のテーブルのリネームで何らかのエラーに遭遇した場合、リネームしたすべてのテーブルを逆にリネームし、すべてを元の状態に戻します。

RENAME TABLE was added in MySQL 3.23.23.

6.5.6 `DROP TABLE` Syntax

DROP [TEMPORARY] TABLE [IF EXISTS] tbl_name [, tbl_name,...] [RESTRICT | CASCADE]

DROP TABLEは、1つ又は1つ以上のテーブルを破棄します。テーブルの全てのデータとテーブル定義は破棄されますので、このコマンドの使用は慎重に行ってください！

MySQL バージョン 3.22以降では、テーブルが存在しないことに起因するエラーを防ぐために、キーワード IF EXISTS を使用することができます。 In 4.1 one gets a NOTE for all not existing tables when using IF EXISTS. 「4.5.6.9 SHOW WARNINGS | ERRORS」節参照. RESTRICT と CASCADE は移植を簡単にするために許されています。しばらくはこれらは何も行ないません。注意: DROP TABLE はトランザクション安全ではなく、自動的にすべてのアクティブトランザクションをコミットします。 (except if you are using 4.1 and the TEMPORARY key word. )

Option TEMPORARY is ignored in 4.0. In 4.1 this option works as follows:

Only drops temporary tables.
It doesn't end a running transactions.
No access rights is checked.

Using TEMPORARY is a good way to ensure that you don't accidently drop a real table.

6.5.7 `CREATE INDEX` 構文

CREATE [UNIQUE|FULLTEXT] INDEX index_name
       ON tbl_name (col_name[(length)],... )

CREATE INDEX 構文は MySQL 3.22 より以前のバージョンではなにもしません。バージョン 3.22 以降で、CREATE INDEX はインデックスの作成のために ALTER TABLE を呼びだしています。 @xref{ALTER TABLE, , ALTER TABLE}.

通常、テーブル内の全てのインデックスは CREATE TABLE でテーブルを作るときに一度に作成されます。「6.5.3 CREATE TABLE 構文」節参照. CREATE INDEX は既に存在するテーブルに対し、インデックスを追加します。 CREATE INDEX allows you to add indexes to existing tables.

フィールドを (col1,col2,...) として指定すると、複数フィールドインデックスを作成します。インデックスの値は、与えられたフィールドの値を連結して、構成されます。

CHAR と VARCHAR フィールドでは、インデックスはフィールドの一部分だけを使用して作成されます。これは col_name(length) 構文を使用します。 (BLOB と TEXT 節では length が必要です)。最初の10文字をインデックスとして使用するには、この構文は以下のようにして使用します(name フィールドにインデックスを作ります)：

mysql> CREATE INDEX part_of_name ON customer (name(10));

フィールドの一部分だけをインデックスに使用すれば、インデックスファイルをはるかに小さくすることができます。ほとんどの名前が最初の10文字において通常異なるので、このインデックスは name フィールド全部を使用して創り出したインデックスに比べて遅くなることはありません。また、多くのディスクスペースを節約でき、 INSERT を速くするのです！

MySQL version 3.23.2 以上で MyISAM 型のテーブルを使用している場合、NULL 値をもつフィールドや、 BLOB/TEXT フィールドに対してインデックスを張ることが可能です。

MySQL がどのようにしてインデックスを使用するかは → 「5.4.3 MySQL はどのようにインデックスを使用するか？」節.

FULLTEXT indexes can index only VARCHAR and TEXT columns, and only in MyISAM tables. FULLTEXT indexes are available in MySQL Version 3.23.23 and later. 「6.8 MySQL Full-text Search」節.

6.5.8 `DROP INDEX` 構文

DROP INDEX index_name ON tbl_name

DROP INDEX は index_name という名前のインデックスをテーブル tbl_name から破棄します。 DROP INDEX は MySQL バージョン 3.22 より以前のバージョンではなにもしません。 3.22 以降で、DROP INDEX はインデックスの破棄のために ALTER TABLE を呼びだしています。「6.5.4 ALTER TABLE 構文」節参照.

6.6 Basic MySQL User Utility Commands

6.6.1 `USE` 構文

USE db_name

USE db_name 構文は、 MySQL に db_name データベースをこの後のクエリのデフォルトのデータベースにするように指示します。指定されたデータベースは、セッションの最後まで、あるいは、他の USE 構文が発行されるまで残ります：

mysql> USE db1;
mysql> SELECT count(*) FROM mytable;      # selects from db1.mytable
mysql> USE db2;
mysql> SELECT count(*) FROM mytable;      # selects from db2.mytable

USE 構文で特定のデータベースをカレントにしても、他のデータベースのテーブルからアクセスすることを妨げません。以下は db1 データベースの author テーブルと、 db2 データベースの editor テーブルにアクセスする例です：

mysql> USE db1;
mysql> SELECT author_name,editor_name FROM author,db2.editor
    ->        WHERE author.editor_id = db2.editor.editor_id;

USE 構文は Sybase の互換のために提供されています。

6.6.2 `DESCRIBE` 構文 (フィールドについての情報を得る)

{DESCRIBE | DESC} tbl_name [col_name | wild]

DESCRIBE is a shortcut for SHOW COLUMNS FROM. 「4.5.6.1 Retrieving information about Database, Tables, Columns, and Indexes」節参照.

DESCRIBE はフィールドについての情報を与えます。 col_name はフィールドはフィールド名または文字列です。文字列は SQL `%',`_' ワイルドカードを含めます。 There is no need to enclose the string in quotes.

もしフィールドの型があなたが CREATE TABLE 文で与えた物と違っているなら、これは MySQL がフィールドの型を変更していることに注意してください。「6.5.3.1 暗黙のフィールド定義変更」節参照.

このコマンドは Oracle の互換のためにあります。

SHOW 構文は似たような情報を提供します。「4.5.6 SHOW 構文」節参照.

6.7 MySQL Transactional and Locking Commands

6.7.1 `BEGIN/COMMIT/ROLLBACK` 構文

デフォルトでは MySQL は autocommit モードで動作します。これは、更新を実行するとすぐに MySQL が更新をディスクに格納することを意味します。

もしトランザクションセーフのテーブル(like BDB, InnoDB) を使用するなら, 以下のコマンドで MySQL を非 autocommit モード状態にすることができます：

SET AUTOCOMMIT=0

この後、ディスクに変更を格納するためには COMMIT を使用し、また、変更を無視するためには ROLLBACK する必要があります。

ある一連のステートメントのために AUTOCOMMIT モードからスイッチしたい場合は、START TRANSACTION か BEGIN または BEGIN WORK ステートメントを使用できます。

START TRANSACTION;
SELECT @A:=SUM(salary) FROM table1 WHERE type=1;
UPDATE table2 SET summmary=@A WHERE type=1;
COMMIT;

START TRANSACTION was added to MySQL 4.0.11; This is the recommended way to start an ad-hoc transaction as this is ANSI SQL syntax. (訳注： 4.0.11より前では、BEGIN を使用します)

注意: トランザクション安全テーブルを使用していない場合は、autocommit モードのステータスには依存せずに、変更はすぐに格納されます。

If you do a ROLLBACK when you have updated a non-transactional table you will get an error (ER_WARNING_NOT_COMPLETE_ROLLBACK) as a warning. All transaction-safe tables will be restored but any non-transaction-safe table will not change.

If you are using START TRANSACTION or SET AUTOCOMMIT=0, you should use the MySQL binary log for backups instead of the older update log. Transactions are stored in the binary log in one chunk, upon COMMIT, to ensure that transactions which are rolled back are not stored. 「4.9.4 The Binary Update Log バイナリ更新ログ (3.23.15以上)」節参照.

The following commands automatically end a transaction (as if you had done a COMMIT before executing the command):

Command	Command	Command
`ALTER TABLE`	`BEGIN`	`CREATE INDEX`
`DROP DATABASE`	`DROP TABLE`	`RENAME TABLE`
`TRUNCATE`

You can change the isolation level for transactions with SET TRANSACTION ISOLATION LEVEL .... 「6.7.3 SET TRANSACTION 構文」節参照.

6.7.2 `LOCK TABLES/UNLOCK TABLES` 構文

LOCK TABLES tbl_name [AS alias] {READ [LOCAL] | [LOW_PRIORITY] WRITE}
            [, tbl_name [AS alias] {READ [LOCAL] | [LOW_PRIORITY] WRITE} ...]
...
UNLOCK TABLES

LOCK TABLES はカレントのスレッドのためにテーブルをロックします。 UNLOCK TABLES はこのスレッドの全てのロックを解除します。カレントスレッドによってロックされた全てのテーブルは、スレッドが他の LOCK TABLES を発行した場合やサーバーが接続を閉じた場合、自動で解除されます。

To use LOCK TABLES in MySQL 4.0.2 you need the global LOCK TABLES privilege and a SELECT privilege on the involved tables. In MySQL 3.23 you need to have SELECT, insert, DELETE and UPDATE privileges for the tables.

The main reasons to use LOCK TABLES are for emulating transactions or getting more speed when updating tables. This is explained in more detail later.

スレッドがテーブルに READ ロックを持つ場合、そのスレッド(と他の全てのスレッド)はテーブルからの読み込みだけができます。スレッドがテーブルに WRITE ロックを持つ場合、このスレッドだけがテーブルの READ と WRITE ができます。他のスレッドはブロックされます。

READ LOCAL と READ の違いは、READ LOCAL は、ロックが保持されている間にコンフリクトしない INSERT ステートメントを実行できることです。ただし、これはロックを保持している間に MySQL の外でデータベースファイルを操作しようとする場合は使用できません。

When you use LOCK TABLES, you must lock all tables that you are going to use and you must use the same alias that you are going to use in your queries! If you are using a table multiple times in a query (with aliases), you must get a lock for each alias!

WRITE ロックは普通、できる限り更新を行わせるため、 READ ロックよりも優先順位が高くなっています。これはあるスレッドが READ ロックをかけ、それ以外のスレッドが WRITE を要求した場合、 READ は、WRITE スレッドがロックをし、それを解除するまで待つということです。 LOW_PRIORITY WRITE を使用すれば、 WRITE ロックを待っているスレッドに READ ロックを得させることができます。 LOW_PRIORITY WRITE は READ ロックをしているスレッドが一つもないとわかっている場合に使用すべきです。

LOCK TABLES works as follows:

Sort all tables to be locked in a internally defined order (from the user standpoint the order is undefined).
If a table is locked with a read and a write lock, put the write lock before the read lock.
Lock one table at a time until the thread gets all locks.

This policy ensures that table locking is deadlock free. There is however other things one needs to be aware of with this schema:

If you are using a LOW_PRIORITY WRITE lock for a table, this means only that MySQL will wait for this particlar lock until there is no threads that wants a READ lock. When the thread has got the WRITE lock and is waiting to get the lock for the next table in the lock table list, all other threads will wait for the WRITE lock to be released. If this becomes a serious problem with your application, you should consider converting some of your tables to transactions safe tables.

You can safely kill a thread that is waiting for a table lock with KILL. 「4.5.5 KILL 構文」節参照.

INSERT DELAYED で使用しているいかなるテーブルも、ロックすべきではありません。この場合 INSERT は別のスレッドで行なわれるからです。

通常、全ての単一の UPDATE 構文においては、テーブルをロックする必要はありません；スレッドは、他のスレッドが現在実行している SQL 文に干渉することができません。これらはテーブルをロックした方がよい、まれな場合です：

テーブルをまとめて多くの操作を実行しようとする場合、使用しようとしているテーブルをロックするととても速くなります。もちろん、他のスレッドは READ ロックされたテーブルの更新はできませんし、他のスレッドは WRITE ロックされたテーブルを読むことはできません。 The reason some things are faster under LOCK TABLES is that MySQL will not flush the key cache for the locked tables until UNLOCK TABLES is called (normally the key cache is flushed after each SQL statement). This speeds up inserting/updateing/deletes on MyISAM tables.
MySQL のトランザクションをサポートしない the storage engine を使用している場合、他のスレッドが SELECT,UPDATE の間に来ないことを保証したいならば、LOCK TABLES を使用する必要があります。次の例は安全のためには LOCK TABLES を必要とします：
```
mysql> LOCK TABLES trans READ, customer WRITE;
mysql> SELECT sum(value) FROM trans WHERE customer_id= some_id;
mysql> UPDATE customer SET total_value=sum_from_previous_statement
    ->        WHERE customer_id=some_id;
mysql> UNLOCK TABLES;
```
LOCK TABLES を使用しない場合、SELECT の実行と UPDATE の実行を行う間に、他のスレッドが新しい trans 行を挿入する隙ができます。

インクリメントアップデイト (UPDATE customer SET value=value+new_value) または LAST_INSERT_ID() 関数の使用により、多くの場合 LOCK TABLES を回避できます。

いくつかの場合、ユーザレベルロック: GET_LOCK() と RELEASE_LOCK() の使用によっても解決できます。これらのロックはサーバ内のハッシュテーブル内に保持され、高速のため pthread_mutex_lock() で実装されました。「6.3.6.2 その他の関数」節参照.

ロックポリシーのさらなる情報については「5.3.1 MySQL はどのようにテーブルをロックするか」節を見てください。

You can lock all tables in all databases with read locks with the FLUSH TABLES WITH READ LOCK command. 「4.5.3 FLUSH 構文」節参照. This is very convenient way to get backups if you have a filesystem, like Veritas, that can take snapshots in time.

NOTE: LOCK TABLES is not transaction-safe and will automatically commit any active transactions before attempting to lock the tables.

6.7.3 `SET TRANSACTION` 構文

SET [GLOBAL | SESSION] TRANSACTION ISOLATION LEVEL
{ READ UNCOMMITTED | READ COMMITTED | REPEATABLE READ | SERIALIZABLE }

Sets the transaction isolation level for the global, whole session or the next transaction.

The default behaviour is to set the isolation level for the next (not started) transaction. If you use the GLOBAL keyword, the statement sets the default transaction level globally for all new connections created from that point on. You will need the SUPER privilege to do this. Using the SESSION keyword sets the default transaction level for all future transactions performed on the current connection.

You can set the default global isolation level for mysqld with --transaction-isolation=.... 「4.1.1 mysqld コマンド行オプション」節参照.

6.8 MySQL Full-text Search

As of Version 3.23.23, MySQL has support for full-text indexing and searching. Full-text indexes in MySQL are an index of type FULLTEXT. FULLTEXT indexes are used with MyISAM tables and can be created from CHAR, VARCHAR, or TEXT columns at CREATE TABLE time or added later with ALTER TABLE or CREATE INDEX. For large datasets, it will be much faster to load your data into a table that has no FULLTEXT index, then create the index with ALTER TABLE (or CREATE INDEX). Loading data into a table that already has a FULLTEXT index will be slower.

Full-text searching is performed with the MATCH() function.

mysql> CREATE TABLE articles (
    ->   id INT UNSIGNED AUTO_INCREMENT NOT NULL PRIMARY KEY,
    ->   title VARCHAR(200),
    ->   body TEXT,
    ->   FULLTEXT (title,body)
    -> );
Query OK, 0 rows affected (0.00 sec)

mysql> INSERT INTO articles VALUES
    -> (NULL,'MySQL Tutorial', 'DBMS stands for DataBase ...'),
    -> (NULL,'How To Use MySQL Efficiently', 'After you went through a ...'),
    -> (NULL,'Optimising MySQL','In this tutorial we will show ...'),
    -> (NULL,'1001 MySQL Tricks','1. Never run mysqld as root. 2. ...'),
    -> (NULL,'MySQL vs. YourSQL', 'In the following database comparison ...'),
    -> (NULL,'MySQL Security', 'When configured properly, MySQL ...');
Query OK, 6 rows affected (0.00 sec)
Records: 6  Duplicates: 0  Warnings: 0

mysql> SELECT * FROM articles
    ->          WHERE MATCH (title,body) AGAINST ('database');
+----+-------------------+------------------------------------------+
| id | title             | body                                     |
+----+-------------------+------------------------------------------+
|  5 | MySQL vs. YourSQL | In the following database comparison ... |
|  1 | MySQL Tutorial    | DBMS stands for DataBase ...             |
+----+-------------------+------------------------------------------+
2 rows in set (0.00 sec)

The MATCH() function performs a natural language search for a string against a text collection (a set of one or more columns included in a FULLTEXT index). The search string is given as the argument to AGAINST(). The search is performed in case-insensitive fashion. For every row in the table, MATCH() returns a relevance value, that is, a similarity measure between the search string and the text in that row in the columns named in the MATCH() list.

When MATCH() is used in a WHERE clause (see example above) the rows returned are automatically sorted with highest relevance first. Relevance values are non-negative floating-point numbers. Zero relevance means no similarity. Relevance is computed based on the number of words in the row, the number of unique words in that row, the total number of words in the collection, and the number of documents (rows) that contain a particular word.

It is also possible to perform a boolean mode search. This is explained later in the section.

The preceding example is a basic illustration showing how to use the MATCH() function. Rows are returned in order of decreasing relevance.

The next example shows how to retrieve the relevance values explicitly. As neither WHERE nor ORDER BY clauses are present, returned rows are not ordered.

mysql> SELECT id,MATCH title,body AGAINST ('Tutorial') FROM articles;
+----+-----------------------------------------+
| id | MATCH (title,body) AGAINST ('Tutorial') |
+----+-----------------------------------------+
|  1 |                        0.64840710366884 |
|  2 |                                       0 |
|  3 |                        0.66266459031789 |
|  4 |                                       0 |
|  5 |                                       0 |
|  6 |                                       0 |
+----+-----------------------------------------+
6 rows in set (0.00 sec)

The following example is more complex. The query returns the relevance and still sorts the rows in order of decreasing relevance. To achieve this result, you should specify MATCH() twice. This will cause no additional overhead, because the MySQL optimiser will notice that the two MATCH() calls are identical and invoke the full-text search code only once.

mysql> SELECT id, body, MATCH (title,body) AGAINST
    -> ('Security implications of running MySQL as root') AS score
    -> FROM articles WHERE MATCH (title,body) AGAINST
    -> ('Security implications of running MySQL as root');
+----+-------------------------------------+-----------------+
| id | body                                | score           |
+----+-------------------------------------+-----------------+
|  4 | 1. Never run mysqld as root. 2. ... | 1.5055546709332 |
|  6 | When configured properly, MySQL ... |   1.31140957288 |
+----+-------------------------------------+-----------------+
2 rows in set (0.00 sec)

MySQL uses a very simple parser to split text into words. A ``word'' is any sequence of characters consisting of letters, digits, `'', and `_'. Any ``word'' that is present in the stopword list or is just too short (3 characters or less) is ignored.

Every correct word in the collection and in the query is weighted according to its significance in the query or collection. This way, a word that is present in many documents will have lower weight (and may even have a zero weight), because it has lower semantic value in this particular collection. Otherwise, if the word is rare, it will receive a higher weight. The weights of the words are then combined to compute the relevance of the row.

Such a technique works best with large collections (in fact, it was carefully tuned this way). For very small tables, word distribution does not reflect adequately their semantic value, and this model may sometimes produce bizarre results.

mysql> SELECT * FROM articles WHERE MATCH (title,body) AGAINST ('MySQL');
Empty set (0.00 sec)

The search for the word MySQL produces no results in the above example, because that word is present in more than half the rows. As such, it is effectively treated as a stopword (that is, a word with zero semantic value). This is the most desirable behaviour -- a natural language query should not return every second row from a 1GB table.

A word that matches half of rows in a table is less likely to locate relevant documents. In fact, it will most likely find plenty of irrelevant documents. We all know this happens far too often when we are trying to find something on the Internet with a search engine. It is with this reasoning that such rows have been assigned a low semantic value in this particular dataset.

As of Version 4.0.1, MySQL can also perform boolean full-text searches using the IN BOOLEAN MODE modifier.

mysql> SELECT * FROM articles WHERE MATCH (title,body)
    ->     AGAINST ('+MySQL -YourSQL' IN BOOLEAN MODE);
+----+------------------------------+-------------------------------------+
| id | title                        | body                                |
+----+------------------------------+-------------------------------------+
|  1 | MySQL Tutorial               | DBMS stands for DataBase ...        |
|  2 | How To Use MySQL Efficiently | After you went through a ...        |
|  3 | Optimising MySQL             | In this tutorial we will show ...   |
|  4 | 1001 MySQL Tricks            | 1. Never run mysqld as root. 2. ... |
|  6 | MySQL Security               | When configured properly, MySQL ... |
+----+------------------------------+-------------------------------------+

This query retrieved all the rows that contain the word MySQL (note: the 50% threshold is not used), but that do not contain the word YourSQL. Note that a boolean mode search does not automatically sort rows in order of decreasing relevance. You can see this from result of the preceding query, where the row with the highest relevance (the one that contains MySQL twice) is listed last, not first. A boolean full-text search can also work even without a FULLTEXT index, although it would be slow.

The boolean full-text search capability supports the following operators:

+: A leading plus sign indicates that this word must be present in every row returned.
-: A leading minus sign indicates that this word must not be present in any row returned.
: By default (when neither plus nor minus is specified) the word is optional, but the rows that contain it will be rated higher. This mimicks the behaviour of MATCH() ... AGAINST() without the IN BOOLEAN MODE modifier.
< >: These two operators are used to change a word's contribution to the relevance value that is assigned to a row. The < operator decreases the contribution and the > operator increases it. See the example below.
( ): Parentheses are used to group words into subexpressions.
~: A leading tilde acts as a negation operator, causing the word's contribution to the row relevance to be negative. It's useful for marking noise words. A row that contains such a word will be rated lower than others, but will not be excluded altogether, as it would be with the - operator.
*: An asterisk is the truncation operator. Unlike the other operators, it should be appended to the word, not prepended.
": The phrase, that is enclosed in double quotes ", matches only rows that contain this phrase literally, as it was typed.

And here are some examples:

apple banana: find rows that contain at least one of these words.
+apple +juice: ... both words.
+apple macintosh: ... word ``apple'', but rank it higher if it also contain ``macintosh''.
+apple -macintosh: ... word ``apple'' but not ``macintosh''.
+apple +(>pie <strudel): ... ``apple'' and ``pie'', or ``apple'' and ``strudel'' (in any order), but rank ``apple pie'' higher than ``apple strudel''.
apple*: ... ``apple'', ``apples'', ``applesauce'', and ``applet''.
"some words": ... ``some words of wisdom'', but not ``some noise words''.

6.8.1 Full-text Restrictions

All parameters to the MATCH() function must be columns from the same table that is part of the same FULLTEXT index, unless the MATCH() is IN BOOLEAN MODE.
The MATCH() column list must exactly match the column list in some FULLTEXT index definition for the table, unless this MATCH() is IN BOOLEAN MODE.
The argument to AGAINST() must be a constant string.

6.8.2 Fine-tuning MySQL Full-text Search

Unfortunately, full-text search has few user-tunable parameters yet, although adding some is very high on the TODO. If you have a MySQL source distribution ( 「2.3 MySQL ソースディストリビューションのインストール」節参照), you can exert more control over full-text searching behaviour.

Note that full-text search was carefully tuned for the best searching effectiveness. Modifying the default behaviour will, in most cases, only make the search results worse. Do not alter the MySQL sources unless you know what you are doing!

The minimum length of words to be indexed is defined by the MySQL variable ft_min_word_len. 「4.5.6.4 SHOW VARIABLES」節参照. Change it to the value you prefer, and rebuild your FULLTEXT indexes. (This variable is only available from MySQL version 4.0.)
The stopword list can be loaded from file specified by ft_stopword_file variable. 「4.5.6.4 SHOW VARIABLES」節参照. Rebuild your FULLTEXT indexes after modifying the stopword list. (This variable is only available from MySQL version 4.0.10 and onwards)
The 50% threshold is determined by the particular weighting scheme chosen. To disable it, change the following line in `myisam/ftdefs.h':
```
#define GWS_IN_USE GWS_PROB
```
To:
```
#define GWS_IN_USE GWS_FREQ
```
Then recompile MySQL. There is no need to rebuild the indexes in this case. Note: by doing this you severely decrease MySQL's ability to provide adequate relevance values for the MATCH() function. If you really need to search for such common words, it would be better to search using IN BOOLEAN MODE instead, which does not observe the 50% threshold.
Sometimes the search engine maintainer would like to change the operators used for boolean full-text searches. These are defined by the ft_boolean_syntax variable. 「4.5.6.4 SHOW VARIABLES」節参照. Still, this variable is read-only, its value is set in `myisam/ft_static.c'.

For those changes that require you to rebuild your FULLTEXT indexes, the easiest way to do so for a MyISAM table is to use the following statement, which rebuilds the index file:

mysql> REPAIR TABLE tbl_name QUICK;

6.8.3 Full-text Search TODO

Make all operations with FULLTEXT index faster.
Proximity operators
Support for "always-index words". They could be any strings the user wants to treat as words, examples are "C++", "AS/400", "TCP/IP", etc.
Support for full-text search in MERGE tables.
Support for multi-byte charsets.
Make stopword list to depend of the language of the data.
Stemming (dependent of the language of the data, of course).
Generic user-suppliable UDF preparser.
Make the model more flexible (by adding some adjustable parameters to FULLTEXT in CREATE/ALTER TABLE).

6.9 MySQL Query Cache (4.0.1以上)

From version 4.0.1, MySQL server features a Query Cache. When in use, the query cache stores the text of a SELECT query together with the corresponding result that was sent to the client. If an identical query is later received, the server will retrieve the results from the query cache rather than parsing and executing the same query again.

NOTE: The query cache does not return stale data. When data is modified, any relevant entries in the query cache are flushed.

The query cache is extremely useful in an environment where (some) tables don't change very often and you have a lot of identical queries. This is a typical situation for many web servers that use a lot of dynamic content.

Below is some performance data for the query cache. (These results were generated by running the MySQL benchmark suite on a Linux Alpha 2 x 500 MHz with 2GB RAM and a 64MB query cache):

If all of the queries you're performing are simple (such as selecting a row from a table with one row); but still differ so that the queries can not be cached, the overhead for having the query cache active is 13%. This could be regarded as the worst case scenario. However, in real life, queries are much more complicated than our simple example so the overhead is normally significantly lower.
Searches after one row in a one row table is 238% faster. This can be regarded as close to the minimum speedup to be expected for a query that is cached.
If you want to disable the query cache code set query_cache_size=0. By disabling the query cache code there is no noticeable overhead. (query cache can be excluded from code with help of configure option --without-query-cache)

6.9.1 How The Query Cache Operates

Queries are compared before parsing, thus

SELECT * FROM tbl_name

and

Select * from tbl_name

are regarded as different queries for query cache, so queries need to be exactly the same (byte for byte) to be seen as identical. In addition, a query may be seen as different if for instance one client is using a new communication protocol format or another character set than another client.

Queries that uses different databases, uses different protocol versions or the uses different default character sets are considered different queries and cached separately.

The cache does work for SELECT CALC_ROWS ... and SELECT FOUND_ROWS() ... type queries because the number of found rows is also stored in the cache.

If query result was returned from query cache then status variable Com_select will not be increased, but Qcache_hits will be. 「6.9.4 Query Cache Status and Maintenance」節参照.

If a table changes (INSERT, UPDATE, DELETE, TRUNCATE, ALTER or DROP TABLE|DATABASE), then all cached queries that used this table (possibly through a MRG_MyISAM table!) become invalid and are removed from the cache.

Transactional InnoDB tables that have been changed will be invalidated when a COMMIT is performed.

A query cannot be cached if it contains one of the functions:

Function Function Function

User-Defined Functions CONNECTION_ID FOUND_ROWS

GET_LOCK RELEASE_LOCK LOAD_FILE

MASTER_POS_WAIT NOW SYSDATE

CURRENT_TIMESTAMP CURDATE CURRENT_DATE

CURTIME CURRENT_TIME DATABASE

ENCRYPT (with one parameter) LAST_INSERT_ID RAND

UNIX_TIMESTAMP (without parameters) USER BENCHMARK

Nor can a query be cached if it contains user variables, references the mysql system database, is of the form SELECT ... IN SHARE MODE, SELECT ... INTO OUTFILE ..., SELECT ... INTO DUMPFILE ... or of the form SELECT * FROM AUTOINCREMENT_FIELD IS NULL (to retrieve last insert id - ODBC work around).

However, FOUND ROWS() will return the correct value, even if the preceding query was fetched from the cache.

In case a query does not use any tables, or uses temporary tables, or if the user has a column privilege for any of the involved tables, that query will not be cached.

Before a query is fetched from the query cache, MySQL will check that the user has SELECT privilege to all the involved databases and tables. If this is not the case, the cached result will not be used.

6.9.2 Query Cache Configuration

The query cache adds a few MySQL system variables for mysqld which may be set in a configuration file, on the command-line when starting mysqld.

query_cache_limit Don't cache results that are bigger than this. (Default 1M).
query_cache_size The amount of memory (specified in bytes) allocated to store results from old queries. If this is 0, the query cache is disabled (default).
query_cache_type This may be set (only numeric) to

Option Description

0 (OFF, don't cache or retrieve results)

1 (ON, cache all results except SELECT SQL_NO_CACHE ... queries)

2 (DEMAND, cache only SELECT SQL_CACHE ... queries)

Inside a thread (connection), the behaviour of the query cache can be changed from the default. The syntax is as follows:

QUERY_CACHE_TYPE = OFF | ON | DEMAND QUERY_CACHE_TYPE = 0 | 1 | 2

Option	Description
0 or OFF	Don't cache or retrieve results.
1 or ON	Cache all results except `SELECT SQL_NO_CACHE ...` queries.
2 or DEMAND	Cache only `SELECT SQL_CACHE ...` queries.

6.9.3 Query Cache Options in `SELECT`

There are two possible query cache related parameters that may be specified in a SELECT query:

Option	Description
`SQL_CACHE`	If `QUERY_CACHE_TYPE` is `DEMAND`, allow the query to be cached. If `QUERY_CACHE_TYPE` is `ON`, this is the default. If `QUERY_CACHE_TYPE` is `OFF`, do nothing.
`SQL_NO_CACHE`	Make this query non-cachable, don't allow this query to be stored in the cache.

6.9.4 Query Cache Status and Maintenance

With the FLUSH QUERY CACHE command you can defragment the query cache to better utilise its memory. This command will not remove any queries from the cache. FLUSH TABLES also flushes the query cache.

The RESET QUERY CACHE command removes all query results from the query cache.

You can check whether the query cache is present in your MySQL version:

mysql> SHOW VARIABLES LIKE 'have_query_cache';
+------------------+-------+
| Variable_name    | Value |
+------------------+-------+
| have_query_cache | YES   |
+------------------+-------+
1 row in set (0.00 sec)

You can monitor query cache performance in SHOW STATUS:

Variable	Description
`Qcache_queries_in_cache`	Number of queries registered in the cache.
`Qcache_inserts`	Number of queries added to the cache.
`Qcache_hits`	Number of cache hits.
`Qcache_lowmem_prunes`	Number of queries that were deleted from cache because of low memory.
`Qcache_not_cached`	Number of non-cached queries (not cachable, or due to `QUERY_CACHE_TYPE`).
`Qcache_free_memory`	Amount of free memory for query cache.
`Qcache_free_blocks`	Number of free memory blocks in query cache.
`Qcache_total_blocks`	Total number of blocks in query cache.

Total number of queries = Qcache_inserts + Qcache_hits + Qcache_not_cached.

The query cache uses variable length blocks, so Qcache_total_blocks and Qcache_free_blocks may indicate query cache memory fragmentation. After FLUSH QUERY CACHE only a single (big) free block remains.

Note: Every query needs a minimum of two blocks (one for the query text and one or more for the query results). Also, every table that is used by a query needs one block, but if two or more queries use same table only one block needs to be allocated.

You can use the Qcache_lowmem_prunes status variable to tune the query cache size. It counts the number of queries that have been removed from the cache to free up memory for caching new queries. The query cache uses a least recently used (LRU) strategy to decide which queries to remove from the cache.

Go to the first, previous, next, last section, table of contents.

フィールドタイプ	`ゼロ'値
`DATETIME`	`'0000-00-00 00:00:00'`
`DATE`	`'0000-00-00'`
`TIMESTAMP`	`00000000000000` (長さは表示サイズに依存します)
`TIME`	`'00:00:00'`
`YEAR`	`0000`

Function	Function	Function
`User-Defined Functions`	`CONNECTION_ID`	`FOUND_ROWS`
`GET_LOCK`	`RELEASE_LOCK`	`LOAD_FILE`
`MASTER_POS_WAIT`	`NOW`	`SYSDATE`
`CURRENT_TIMESTAMP`	`CURDATE`	`CURRENT_DATE`
`CURTIME`	`CURRENT_TIME`	`DATABASE`
`ENCRYPT` (with one parameter)	`LAST_INSERT_ID`	`RAND`
`UNIX_TIMESTAMP` (without parameters)	`USER`	`BENCHMARK`

Option	Description
0	(OFF, don't cache or retrieve results)
1	(ON, cache all results except `SELECT SQL_NO_CACHE ...` queries)
2	(DEMAND, cache only `SELECT SQL_CACHE ...` queries)