ストレージエンジンは、データを受け取るけれども破棄して格納しない「ブラックホール」として機能します。検索は、常に空の結果を返します。オプションで呼び出します。ディレクトリを検索します。テーブルを作成するときに、サーバーはデータベースディレクトリ上にテーブルフォーマットファイルを作成します。テーブルに関連するファイルはほかにありません。ストレージエンジンはすべての種類のインデックスをサポートしています。テーブル定義にインデックス宣言を含めることができます。ステートメントで使用できるかどうかを確認できます。ステートメントはログが記録されてスレーブサーバーに複製されます。これは、繰り返しまたはフィルタメカニズムとして役立つ場合があります。注記バイナリログに行ベースフォーマットを使用すると、更新と削除はスキップされ、ログも適用されません。アプリケーションがスレーブ側フィルタリングルールを要求するけれども、すべてのバイナリログデータを最初にスレーブに転送するとトラフィックが多すぎるとします。「dummy」スレーブプロセスをセットアップできます。マスターはそのバイナリログに書き込みます。ルールの適切な組み合わせを適用し、それ自体のフィルタリングされた新しいバイナリログを書き込みます。セクション17.1.4「レプリケーションおよびバイナリロギングのオプションと変数」を参照してください。フィルタリングされたこのログはスレーブに提供されます。プロセスを実行することによる処理オーバーヘッドはほとんどありません。この種類のセットアップは、ほかのレプリケーションスレーブで繰り返すことができます。トリガーは期待どおりに機能します。トリガーは有効ではありません。句は、行がないために適用されません。ストレージエンジンのその他の利用方法は、次のとおりです。ダンプファイル構文の検証。利用して比較することで)。「no-op」ストレージエンジンであるため、ストレージエンジン自体には関係ないパフォーマンスボトルネックの検出に使用される場合があります。エンジンはトランザクション対応です。使用してテーブルで実行される操作は効果がありません。このことは、自動的に増分する主キーカラムの動作を考慮するときに念頭におくようにしてください。このエンジンはフィールド値を自動的に増分せず、自動インクリメントフィールドの状態を保持しません。これは、レプリケーションで重要な意味を持ちます。つの条件がすべて適用される次のレプリケーションシナリオを検討します。マスターサーバーには、主キーである自動インクリメントフィールドを持つブラックホールテーブルがあります。エンジンを使用します。ステートメントを使用して、マスターのテーブルへの挿入が実行されます。このシナリオでは、レプリケーションは主キーカラムでの重複エントリーエラーで失敗します。値は常に同じになります。このため、主キーカラムで重複値を持つ行を挿入しようとすると、レプリケーションは失敗します。行ベースのレプリケーションでは、エンジンが戻す行の値は、各挿入で常に同じです。つの挿入ログエントリーを再生しようとして、レプリケーションは失敗します。セクション17.4.1.9「テーブル定義が異なるマスターとスレーブでのレプリケーション」セクションで説明されたように、最後のカラムがテーブルから失われたスレーブがサポートされます。このフィルタリングはスレーブ側で機能します。カラムはフィルタリングされる前にスレーブにコピーされます。データが機密の場合、スレーブサーバーはアクセスすべきではありません。マスターが多くのスレーブを持つ場合、スレーブに送る前にフィルタリングすると、ネットワークトラフィックが削減される可能性があります。エンジンを使用して実現できます。類似した方法で実行されます。マスターのセットアップは次のとおりです。ENGINE=MyISAM;信頼されたスレーブのセットアップは次のとおりです。ENGINE=BLACKHOLE;信頼されないスレーブのセットアップは次のとおりです。