HANDLERtbl_name
OPEN [ [AS]alias
] HANDLERtbl_name
READindex_name
{ = | >= | <= | < } (value1
,value2
,...) [ WHEREwhere_condition
] [LIMIT ... ] HANDLERtbl_name
READindex_name
{ FIRST | NEXT | PREV | LAST } [ WHEREwhere_condition
] [LIMIT ... ] HANDLERtbl_name
READ { FIRST | NEXT } [ WHEREwhere_condition
] [LIMIT ... ] HANDLERtbl_name
CLOSE
HANDLER
ステートメントは、テーブルストレージエンジンインタフェースへの直接アクセスを供給します。これは
MyISAM
と
InnoDB
テーブルに有効です。
HANDLER ... OPEN
ステートメントはテーブルをオープンし、それに続く
HANDLER ... READ
ステートメントを通してテーブルをアクセス可能にします。このテーブルオブジェクトはほかのセッションによって共有されておらず、このセッションが
HANDLER ... CLOSE
を呼び出すか、またはこのセッションが終了するまで閉じられません。もしエイリアスを利用してテーブルをオープンすると、別の
HANDLER
ステートメントを利用しているオープンされたテーブルへの更なる参照時には、テーブル名ではなくエイリアスを利用しなければいけません。
最初の HANDLER ... READ
構文は、指定されたインデックスが与えられた値を満たし
WHERE
条件が一致する行をフェッチします。もし複合カラムインデックスがあるなら、インデックスカラム値をカンマで区切られたリストで指示してください。インデックス内のすべてのカラムに値を指定するか、インデックスカラムの左端の接頭辞に値を指定してください。インデックス
my_idx
が
col_a
、col_b
、そして
col_c
という名前の 3
つのカラムをこの通りの順番で含むと仮定してください。HANDLER
ステートメントはインデックス内の 3
つすべてのカラム、または左端の接頭辞内のカラムに値を指定することができます。例
:
HANDLER ... READ my_idx = (col_a_val,col_b_val,col_c_val) ... HANDLER ... READ my_idx = (col_a_val,col_b_val) ... HANDLER ... READ my_idx = (col_a_val) ...
テーブルの PRIMARY
KEY
を参照するために
HANDLER
インタフェースを利用するには、引用識別子の
`PRIMARY`
を利用してください。
HANDLER tbl_name
READ `PRIMARY` ...
2 つめの HANDLER ... READ
構文は WHERE
条件に合うインデックス順でテーブルから行をフェッチします。
2 つめの HANDLER ... READ
構文は WHERE
条件に合うインデックス順でテーブルから行をフェッチします。これは、完全なテーブルスキャンが必要な場合は
HANDLER
より高速です。自然な行の順番というのは、tbl_name
READ
index_name
MyISAM
テーブルデータファイルの中で行が格納されている順番です。このステートメントは
InnoDB
テーブルにも機能しますが、別のデータファイルがないので同じようなコンセプトはありません。
HANDLER ... READ
のすべての形は単列が空いていれば
LIMIT
なしでそれをフェッチします。指定した行数を返すためには
LIMIT
節を含んでください。これは、SELECT
ステートメントと同じ構文を持ちます。項8.2.8. 「SELECT
構文」
を参照してください。
HANDLER ... CLOSE
は
HANDLER ... OPEN
がオープンしたテーブルを閉じます。
通常の SELECT
ステートメントの代わりに、HANDLER
インタフェースを利用するのにはいくつかの理由があります。
HANDLER
は
SELECT
よりも速いです。
指定されたストレージエンジンハンドラオブジェクトは
HANDLER ... OPEN
に割り当てられます。そのオブジェクトは、そのテーブルの後続
HANDLER
ステートメントに再利用されます。それぞれに対して再初期化する必要はありません。
解析はあまり行われません。
オプティマイザやクエリチェックなどのオーバーヘッドはありません。
2 つのハンドラ要求間でテーブルがロックされる必要はありません。
ハンドラインタフェースはデータの統一をする必要がありませんので
(たとえばダーティー読み取りが許されています)、ストレージエンジンは
SELECT
が通常は許容しない最適化機能を利用することができます。
ISAM
のようなインタフェースを利用するアプリケーションに対しては、HANDLER
のおかげでそれらを MySQL
にポートするのが簡単になります。
HANDLER
のおかげで、SELECT
では難しい (または不可能な)
方法でデータベースをスキャンすることができます。データベースに対話式のユーザーインタフェースを提供するアプリケーションを利用するときには、HANDLER
インタフェースの方がより自然な方法です。
HANDLER
は若干低レベルなステートメントです。たとえば、これは一貫性を持ちません。これは、HANDLER
... OPEN
はテーブルのスナップショットを
撮らない、またテーブルを
ロックしない
ということです。つまり、HANDLER
... OPEN
ステートメントが発行されたあと、テーブルデータを
(現在のセッションまたはその他のセッションで)
変更することができ、HANDLER
... NEXT
または HANDLER
... PREV
スキャンは部分的にしかこれらの変更を検出できない可能性があります。
開いているハンドラを閉じて、再度開くようにマークすることができます。この場合、このハンドラはテーブル内の位置を失います。これは、次の両方の状況が当てはまる場合に発生します。
このハンドラのテーブル上で、任意のセッションが
FLUSH
TABLES
または DDL
ステートメントを実行している。
このハンドラを開いているセッションが、テーブルを使用する
HANDLER
以外のステートメントを実行している。