13.2.4 HANDLER 構文

HANDLER tbl_name OPEN [ [AS] alias]

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

HANDLER tbl_name CLOSE

HANDLER ステートメントは、テーブルストレージエンジンインタフェースへの直接アクセスを提供します。これは、InnoDB および MyISAM テーブルに使用できます。

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) ...

HANDLER インタフェースを使用してテーブルの PRIMARY KEY を参照するには、引用符で囲まれた識別子 `PRIMARY` を使用します。

HANDLER tbl_name READ `PRIMARY` ...

2 番目の HANDLER ... READ 構文は、WHERE 条件に一致するインデックス順序でテーブルの行をフェッチします。

3 番目の HANDLER ... READ 構文は、WHERE 条件に一致する自然な行順序でテーブルの行をフェッチします。これは、フルテーブルスキャンが望ましい場合は、HANDLER tbl_name READ index_name より高速です。自然な行順序とは、行が MyISAM テーブルデータファイル内に格納されている順序のことです。このステートメントは InnoDB テーブルに対しても機能しますが、個別のデータファイルが存在しないため、このような概念はありません。

LIMIT 句を使用しない場合は、すべての形式の HANDLER ... READ が単一行 (使用可能な場合) をフェッチします。特定の行数を返すには、LIMIT 句を含めます。その構文は、SELECT ステートメントの場合と同じです。セクション13.2.9「SELECT 構文」を参照してください。

HANDLER ... CLOSE は、HANDLER ... OPEN でオープンされたテーブルをクローズします。

通常の SELECT ステートメントの代わりに HANDLER インタフェースを使用する理由として、次のいくつかがあります。

• HANDLER は SELECT より高速です。

  • HANDLER ... OPEN に対して、指定されたストレージエンジンハンドラオブジェクトが割り当てられます。このオブジェクトは、そのテーブルに対する以降の HANDLER ステートメントに再利用されます。ステートメントごとに再初期化する必要はありません。

  • 関連する解析が少なくなります。

  • オプティマイザまたはクエリーチェックのオーバーヘッドがありません。

  • ハンドラインタフェースは (たとえば、ダーティー読み取りが許可されるような) データの整合性のある外観を提供する必要がないため、ストレージエンジンは、SELECT が通常は許可しない最適化を使用できます。

• HANDLER によって、ISAM に似た低レベルのインタフェースを使用する MySQL アプリケーションへの移植が容易になります。(キー値格納パラダイムを使用するアプリケーションを適応させるための代替手段については、セクション14.18「InnoDB と memcached の統合」を参照してください。)

• HANDLER を使用すると、SELECT では実現が困難な (または、不可能でさえある) 方法でデータベースをたどることができます。HANDLER インタフェースは、データベースに対話型ユーザーインタフェースを提供するアプリケーションの操作時にデータを調べるためのより自然な方法です。

HANDLER は、やや低レベルのステートメントです。たとえば、一貫性が提供されません。つまり、HANDLER ... OPEN はテーブルのスナップショットを作成せず、テーブルのロックも行いません。これは、HANDLER ... OPEN ステートメントが発行されたあと、テーブルデータを (現在のセッションまたはその他のセッションで) 変更することができ、これらの変更が HANDLER ... NEXT または HANDLER ... PREV スキャンに部分的にしか表示されない可能性があることを示します。

開かれたハンドラを閉じ、再度開くようにマークすることができます。その場合、このハンドラはテーブル内の位置を失います。これは、次の両方の状況が当てはまる場合に発生します。

• このハンドラのテーブルに対して、いずれかのセッションが FLUSH TABLES または DDL ステートメントを実行している。

• このハンドラを開いているセッションが、テーブルを使用する HANDLER 以外のステートメントを実行している。

テーブルに対する TRUNCATE TABLE は、HANDLER OPEN で開かれたそのテーブルのすべてのハンドラを閉じます。

FLUSH TABLES tbl_name WITH READ LOCK でフラッシュされたテーブルが HANDLER で開かれた場合、そのハンドラは暗黙的にフラッシュされ、その位置を失います。

HANDLER は、パーティション化されたテーブルではサポートされません。