各 select_expr は、検索したいカラムを指示します。少なくとも 1 つの select_expr が必要です。

table_references はどのテーブルから行の検索をするかを指示します。その構文は 項8.2.8.1. 「JOIN 構文」 で説明されています。

WHERE 節が指定された場合は、選択されるために行が満たす必要のある (1 つまたは複数の) 条件を示します。where_condition は、選択される行ごとに true に評価される式です。ステートメントは、もし WHERE 節がなければすべての行を選択します。

WHERE 節の中では、総計 (要約) 関数以外の、MySQL がサポートする関数や演算子のすべてを利用することができます。章 7. 関数と演算子 を参照してください。

修飾されていない 1 つの * のみから成る選択リストを、すべてのテーブルのすべてカラムを選択するための短縮形として使用できます。

SELECT * FROM t1 INNER JOIN t2 ...

tbl_name.* は、指定されたテーブルのすべてのカラムを選択するための修飾された短縮形として使用できます。

SELECT t1.*, t2.* FROM t1 INNER JOIN t2 ...

修飾されていない * を選択リスト内のほかの項目とともに使用することによって、解析エラーが発生する場合があります。この問題を回避するには、修飾された tbl_name.* 参照を使用します。

SELECT AVG(score), t1.* FROM t1 ...

AS alias_name を使用して、select_expr にエイリアスを指定できます。そのエイリアスは、式のカラム名として利用され、GROUP BY、ORDER BY、または HAVING 節内で利用することができます。例 :

SELECT CONCAT(last_name,', ',first_name) AS full_name
  FROM mytable ORDER BY full_name;

AS キーワードは、select_expr をエイリアスを指定するときには任意です。前出の例はこのように書くことが可能でした。

SELECT CONCAT(last_name,', ',first_name) full_name
  FROM mytable ORDER BY full_name;

しかし、AS が任意なので、2 つの select_expr 式の間のカンマを忘れると、わずかなエラーが発生することがあります。MySQL は 2 番目をエイリアスだと解釈します。たとえば次のステートメントの中で、columnb はエイリアスとして扱われています。

SELECT columna columnb FROM mytable;

この理由のため、カラムのエイリアスを指定するときには AS を明示的に利用する癖をつけておくと良いでしょう。

WHERE 節が実行されるときにはカラム値がまだ決定されていない可能性があるため、WHERE 節でカラムのエイリアスを参照することは許可されていません。Problems with Column Aliases を参照してください。

FROM table_references 節は、行を取り出す (1 つまたは複数の) テーブルを示します。もし複数のテーブルに名前をつけると、それは結合を実行するということになります。結合構文の情報に関しては、項8.2.8.1. 「JOIN 構文」 を参照してください。指定された各テーブルにエイリアスを任意で指定することができます。

tbl_name [[AS] alias] [index_hint]

インデックスヒントを使用すると、クエリー処理中にインデックスを選択する方法に関する情報がオプティマイザに提供されます。これらのヒントを指定するための構文については、項8.2.8.2. 「インデックスヒントの構文」 を参照してください。

代わりの方法として SET max_seeks_for_key=value を使用して、MySQL にテーブルスキャンの代わりにキースキャンを強制的に実行させることができます。Server System Variables を参照してください。

データベースを明示的に指定するために、デフォルトデータベース内で tbl_name、または db_name.tbl_name としてテーブルを参照することができます。col_name、tbl_name.col_name、または db_name.tbl_name.col_name としてカラムを参照することができます。参照があいまいにならなければ、カラムの参照に tbl_name か db_name.tbl_name 接頭辞を指定する必要はありません。さらに明確なカラム参照フォームを必要とする例に関しては、項5.2.1. 「識別子の修飾語」 を参照してください。

tbl_name AS alias_name または tbl_name alias_name を使用して、テーブル参照にエイリアスを指定できます。

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

SELECT t1.name, t2.salary FROM employee t1, info t2
  WHERE t1.name = t2.name;

カラム名、カラムのエイリアス、またはカラム位置を使用して、出力のために選択されたカラムを ORDER BY および GROUP BY 節で参照できます。カラム位置は整数で、1 から始まります。

SELECT college, region, seed FROM tournament
  ORDER BY region, seed;

SELECT college, region AS r, seed AS s FROM tournament
  ORDER BY r, s;

SELECT college, region, seed FROM tournament
  ORDER BY 2, 3;

逆の順番にソートするためには、ソートに利用している ORDER BY 節の中で、カラム名に DESC (降順) キーワードを追加してください。デフォルトは昇順です。これは ASC キ－ワードを利用して明示的に指定することができます。

ORDER BY がサブクエリー内に指定され、外側のクエリーにも指定される場合は、もっとも外側の ORDER BY が優先されます。たとえば、次のステートメントの結果は昇順ではなく、降順でソートされます。

(SELECT ... ORDER BY a) ORDER BY a DESC;

カラム位置の利用は、構文が SQL スタンダードから削除されたために今後廃止される可能性があります。

GROUP BY を使用すると、出力行は、同じカラムに対して ORDER BY を指定したかのように GROUP BY カラムに従ってソートされます。GROUP BY が生成するソートのオーバーヘッドを防ぐには、ORDER BY NULL を追加してください。

SELECT a, COUNT(b) FROM test_table GROUP BY a ORDER BY NULL;

MySQL では GROUP BY 節が拡張され、この節で指定されているカラムのあとに ASC と DESC も指定できるようになっています。

SELECT a, COUNT(b) FROM test_table GROUP BY a DESC;

MySQL は、GROUP BY 節内で言及されていないフィールドの選択を許可するために、GROUP BY の利用を拡張します。もしクエリーから期待通りの結果を得ることができないのであれば、項7.12. 「GROUP BY 節との関数および修飾子の使用」 内の GROUP BY の説明を読んでください。

GROUP BY は WITH ROLLUP 修飾子を許容します。項7.12.2. 「GROUP BY 修飾子」 を参照してください。

HAVING 節は、ほぼ最後 (項目がクライアントに送信される直前) に最適化なしで適用されます。(LIMIT は HAVING のあとに適用されます。)

SQL スタンダードは HAVING が GROUP BY 節の中、または総計関数の中で利用されるカラムだけを参照することを要求します。しかし、MySQL はこの動作に拡張子をサポートし、HAVING が SELECT リストの中のカラムと外部のサブクエリーの中のカラムを参照することを許容します。

もし HAVING 節があいまいなカラムを参照すると、警告が発生します。次のステートメントの中では、エイリアスとカラム名の両方として利用されているため col2 はあいまいです。

SELECT COUNT(col1) AS col2 FROM t GROUP BY col2 HAVING col2 = 2;

スタンダード SQL の動作には優先権が与えられるので、もし HAVING カラム名が GROUP BY と、出力カラムリスト内のエイリアスカラムの両方で利用されると、優先権は GROUP BY カラム内のカラムに与えられます。

HAVING は、WHERE 節内になければいけない項目に対しては利用しないでください。たとえば、次のようなものを書かないでください。

SELECT col_name FROM tbl_name HAVING col_name > 0;

代わりにこのように書いてください。

SELECT col_name FROM tbl_name WHERE col_name > 0;

HAVING 節は WHERE 節が参照できない総計関数を参照することができます。

SELECT user, MAX(salary) FROM users
  GROUP BY user HAVING MAX(salary) > 10;

(これは MySQL の古いバージョンでは機能しませんでした)。

MySQL は複製カラム名を許容します。これは、同じ名前の select_expr が複数存在できるということです。これは標準 SQL へのエクステンションです。MySQL はまた GROUP BY と HAVING が select_expr 値を参照することを許容するので、この結果はあいまいになり得ます。

SELECT 12 AS a, a FROM t GROUP BY a;

このステートメントの中では、両方のカラムが a という名前を持ちます。グループ分けに正しいカラムを利用することを保障するために、各 select_expr に異なる名前を利用してください。

MySQL は select_expr 値の中、そして FROM 節内のテーブルカラムの中を検索することで ORDER BY 節内の無条件のカラムやエイリアス参照を解決します。GROUP BY か HAVING 節に対しては、select_expr 値内を検索する前に FROM 節を検索します。GROUP BY と HAVING に対しては、ORDER BY に対するのと同じ規則を利用した MySQL 5.0 以前の動作とは異なります)。

LIMIT 節を使用すると、SELECT ステートメントによって返される行数を制約できます。LIMIT は 1 つまたは 2 つの数値引数を取り、この両方が負でない整定数である必要があります (準備済みステートメントを使用している場合を除く)。

その 2 つの引数のうち、最初のものは返される最初の行のオフセットを指定し、2 つめのものは返される行の最高数を指定します。冒頭の行のオフセットは 0 です。(1 ではありません)

SELECT * FROM tbl LIMIT 5,10;  # Retrieve rows 6-15

すべての行を一定のオフセットから結果セットの最後まで検索するには、2 つめのパラメータに大きい数字を利用することができます。このステートメントは 96 番目の行から最後まですべての行を検索します。

SELECT * FROM tbl LIMIT 95,18446744073709551615;

1 つの引数で、その値は結果セットの最初から返される行数を指定します。

SELECT * FROM tbl LIMIT 5;     # Retrieve first 5 rows

つまり、LIMIT row_count は LIMIT 0, row_count と同等です。

準備済みステートメントには、プレースホルダを利用することができます。次のステートメントは tbl テーブルから行を 1 つ返します。

SET @a=1;
PREPARE STMT FROM 'SELECT * FROM tbl LIMIT ?';
EXECUTE STMT USING @a;

次のステートメントは tbl テーブルから 2 行目から 6 行目を返します。

SET @skip=1; SET @numrows=5;
PREPARE STMT FROM 'SELECT * FROM tbl LIMIT ?, ?';
EXECUTE STMT USING @skip, @numrows;

PostgreSQL との互換性のために、MySQL は LIMIT row_count OFFSET offset 構文もサポートしています。

LIMIT がサブクエリー内に指定され、外側のクエリーでも指定される場合は、もっとも外側の LIMIT が優先されます。たとえば、次のステートメントは、1 行ではなく 2 行を生成します。

(SELECT ... LIMIT 1) LIMIT 2;

PROCEDURE 節は、結果セット内のデータを処理する必要のあるプロシージャーを指定します。1 つの例として、PROCEDURE ANALYSE を参照してください。ここには、テーブルサイズの削減に役立つ最適なカラムデータ型についてのヒントを得るために使用できるプロシージャー ANALYSE が説明されています。

SELECT の SELECT ... INTO OUTFILE 'file_name' 形式は、選択された行をファイルに書き込みます。このファイルはサーバーホスト上で作成されるため、この構文を使用するための FILE 権限を持っている必要があります。file_name を既存のファイルにすることはできません。これにより、特に、/etc/passwd やデータベーステーブルなどのファイルが破壊されることが回避されます。MySQL 5.1.6 では、character_set_filesystem システム変数によってファイル名の解釈が制御されます。

SELECT ... INTO OUTFILE ステートメントはそもそも、サーバーマシン上のテキストファイルにテーブルをすばやく捨てさせることを意図しています。もしサーバーホストではなく、クライアントホスト上に結果ファイルを作成したければ、SELECT ... INTO OUTFILE を利用することはできません。その場合は、代わりに mysql -e "SELECT ..." > file_name などのコマンドを使用してクライアントホスト上でファイルを生成するようにしてください。

SELECT ... INTO OUTFILE は、LOAD DATA INFILE を補完するものです。カラム値は、CHARACTER SET 節 (MySQL 5.1.38 で使用可能) で指定されたキャラクタセットに変換されて書き込まれます。5.1.38 より前のバージョンでは、またはこのような節が存在しない場合、値は binary キャラクタセットを使用してダンプされます。事実上、キャラクタセットの変換は実行されません。テーブルに複数のキャラクタセットのカラムが含まれている場合は、出力データファイルにも同様に含まれるため、ファイルを正しく再ロードできない可能性があります。

このステートメントの export_options 部分の構文は、LOAD DATA INFILE ステートメントで使用されるのと同じ FIELDS および LINES 節で構成されています。

FIELDS ESCAPED BY は、特別な文字をどのように書き込むのかをコントロールします。もし FIELDS ESCAPED BY 文字が空でなければ、それは出力上で次の文字に先行する接頭辞として利用されます。

FIELDS TERMINATED BY、ENCLOSED BY、ESCAPED BY、または LINES TERMINATED BY 文字は、ファイルを確実に読み返すことができるように、エスケープする必要があります。ASCII NUL は、一部のページャーで見やすくなるようにエスケープされます。

結果のファイルは SQL 構文と一致する必要がないので、ほかのものは拡張される必要はありません。

もし FIELDS ESCAPED BY 文字が空なら、文字が拡張されることはなく、NULL は \N ではなく NULL として出力されます。特に、もしデータ中のにフィールド値が先ほどのリストの中の文字を含んでいる場合は、空の拡張文字を指定するのは良い考えではないかも知れません。

ここに、多くのプログラムで利用されるカンマで区切られた値 (CSV) のフォーマットのファイルを生成する例があります。

SELECT a,b,a+b INTO OUTFILE '/tmp/result.txt'
  FIELDS TERMINATED BY ',' OPTIONALLY ENCLOSED BY '"'
  LINES TERMINATED BY '\n'
  FROM test_table;

FIELDS および LINES 節のデフォルト値や許可される値などの詳細については、項8.2.6. 「LOAD DATA INFILE 構文」 を参照してください。

INTO OUTFILE の代わりに INTO DUMPFILE を使用する場合、MySQL は、カラムまたは行の終了処理やエスケープ処理を行わずに、ファイルに 1 行のみを書き込みます。これは、もしファイルの中に BLOB 値を格納したいのであれば有効です。

INTO 節には、1 つ以上の変数のリストを指定できます。ここには、ユーザー定義変数、またはストアドファンクションまたはプロシージャー本体内のパラメータまたはローカル変数を指定できます (項8.8.3.3. 「SELECT ... INTO ステートメント」 を参照)。選択された値は変数に割り当てられます。変数の数はカラム数と一致する必要があります。クエリーは、単一行を返すようにしてください。クエリーが行を返さない場合は、エラーコード 1329 で警告が発生し (No data)、変数値は変更されずに残ります。クエリーが複数の行を返す場合は、エラー 1172 が発生します (Result consisted of more than one row)。ステートメントで複数の行を取り出すことができる場合は、LIMIT 1 を使用して結果セットを単一行に制限できます。

イベントスケジューラによって実行されるイベントの一部として発生するこのようなステートメントのコンテキストでは、診断メッセージ (エラーだけでなく、警告も) がエラーログに書き込まれます。また、Windows では、アプリケーションイベントログに書き込まれます。追加情報については Event Scheduler Status を参照してください。

この節の最初の SELECT 構文の説明で、ステートメントの終わりの方の INTO 節が表されています。また、select_expr リストの直後に INTO を使用することもできます。

入れ子の SELECT は結果を外側のコンテキスト返す必要があるため、このような SELECT では INTO 節を使用しないようにしてください。

ページまたは行のロックを使用するストレージエンジンで FOR UPDATE を使用する場合、クエリーによって検証される行は、現在のトランザクションの最後まで書き込みがロックされます。LOCK IN SHARE MODE を利用すると、ほかのトランザクションが検査された行を読むことは許容しますが、それらを更新や削除することは許容しない共通ロックを設定します。項9.8.3. 「SELECT ... FOR UPDATE と SELECT ... LOCK IN SHARE MODE ロック読み取り」 を参照してください。

HIGH_PRIORITY は SELECT に、テーブルを更新するステートメントより高い優先度を与えます。これは、スピードがとても速く、一度に実行されなければいけないクエリーに対してだけ利用してください。読み込みのためにテーブルがロックされている間に発行された SELECT HIGH_PRIORITY クエリーは、テーブルがフリーになるのを待っている更新ステートメントがあったとしても実行します。これは、テーブルレベルロックのみを使用するストレージエンジン (MyISAM、MEMORY、MERGE) にのみ影響を与えます。

HIGH_PRIORITY は、UNION の一部である SELECT ステートメントと一緒には利用できません。

STRAIGHT_JOIN は、オプティマイザに、テーブルを FROM 節にリストされている順序で強制的に結合させます。オプティマイザがテーブルを最適でない順序で結合する場合は、これを使用してクエリーを高速化できます。STRAIGHT_JOIN はまた table_references リストの中でも利用できます。項8.2.8.1. 「JOIN 構文」 を参照してください。

STRAIGHT_JOIN は、オプティマイザが const テーブルまたは system テーブルとして処理するテーブルには適用されません。このようなテーブルは単一行を生成し、クエリー実行の最適化フェーズ中に読み取られます。また、そのカラムへの参照は、クエリー実行が続行される前に適切なカラム値で置き換えられます。これらのテーブルは、EXPLAIN によって表示されるクエリープランに最初に表示されます。詳しくは項4.2.1. 「EXPLAIN を使用して、クエリーを最適化する」を参照してください。この例外は、外部結合の NULL で補完された側で使用されている const テーブルまたは system テーブル (つまり、LEFT JOIN の右側のテーブルまたは RIGHT JOIN の左側のテーブル) には適用されない可能性があります。

SQL_BIG_RESULT を GROUP BY または DISTINCT とともに使用すると、結果セットに多数の行が含まれていることをオプティマイザに指示できます。この場合、MySQL は必要であればディスクベースの一時テーブルを直接利用し、GROUP BY 要素上のキーを持つ一時テーブルを利用してソートします。

SQL_BUFFER_RESULT は、結果を強制的に一時テーブルに配置します。これは、MySQL がテーブルロックを早く解除するのを助け、クライアントに結果セットを送るのに時間がかかる場合に補助します。このオプションは、サブクエリーまたは後続の UNION ではなく、トップレベルの SELECT ステートメントでのみ使用できます。

SQL_SMALL_RESULT を GROUP BY または DISTINCT とともに使用すると、結果セットが小さいことをオプティマイザに指示できます。この場合、MySQL は結果テーブルを格納するため、ソート機能を利用する代わりに高速の一時テーブルを利用します。通常これは必要ではないでしょう。

SQL_CALC_FOUND_ROWS は MySQL に、LIMIT 節をすべて無視して、結果セットに含まれる数行を計算するよう指示します。行数は SELECT FOUND_ROWS() を利用して検索することができます。項7.11.3. 「情報関数」 を参照してください。

SQL_CACHE および SQL_NO_CACHE オプションは、クエリーキャッシュ内のクエリー結果のキャッシュに影響を与えます (項4.5.5. 「MySQL クエリキャッシュ」 を参照)。SQL_CACHE は MySQL に、結果がキャッシュ可能であり、query_cache_type システム変数の値が 2 または DEMAND である場合は、結果をクエリーキャッシュに格納するよう指示します。SQL_NO_CACHE は MySQL に、結果をクエリーキャッシュに格納しないよう指示します。UNION、サブクエリー、またはビューを使用するクエリーの場合は、次の規則が適用されます。