BLACKHOLE ストレージエンジンは データを受け入れますがそれを格納せずに捨ててしまう「black hole」として機能します。検索しても結果は得られません。

mysql> CREATE TABLE test(i INT, c CHAR(10)) ENGINE = BLACKHOLE;
Query OK, 0 rows affected (0.03 sec)

mysql> INSERT INTO test VALUES(1,'record one'),(2,'record two');
Query OK, 2 rows affected (0.00 sec)
Records: 2  Duplicates: 0  Warnings: 0

mysql> SELECT * FROM test;
Empty set (0.00 sec)

ソースからMySQLを構築し BLACKHOLE ストレージエンジンの機能を有効にするには、--with-blackhole-storage-engine　オプションの　configure コマンドを呼び出します。

BLACKHOLE エンジンのソースを調べるには、MySQL ソースディストリビューションの sql ディレクトリを検索します。

BLACKHOLE　テーブルを作成すると、サーバーはデータベースのディレクトリ上にテーブル形式のファイルを作成します。ファイルはテーブル名から始まり .frm 拡張子が付きます。テーブルに関連する他のファイルはありません。

BLACKHOLE ストレージエンジンは全てのインデックスをサポートします。それは、インデックスデクラレーションをテーブル定義に含む事ができるという事を意味します。

このステートメントを使って BLACKHOLE ストレージエンジンが有効かどうかを調べる事が出来ます。

mysql> SHOW VARIABLES LIKE 'have_blackhole_engine';

BLACKHOLE テーブルへ挿入してもデータは格納されませんが、　バイナリログが有効な場合、SQLステートメントはログされます。(そしてスレーブサーバーに複製されます。)これはリピータやフィルタメカニズムに有用です。例えば、アプリケーションがスレーブサイドフィルタルールを要求したとします。しかし、スレーブに全てのバイナリログデータを転送すると、すぐにトラフィックが混み合ってしまいます。そのような場合は、次に描かれているようにマスタホスト上に、デフォルトストレージエンジンがBLACKHOLEである「dummy」スレーブプロセスをセットアップする事が可能です。

マスタはそれ自体のバイナリログに書き込みを行います。「dummy」 mysqldプロセスは、希望のreplicate-do-* と replicate-ignore-* ルールの組み合わせを適応させスレーブとして機能し、それ自体の新しくフィルタされたバイナリログを書きます。（詳しくは項5.1.3. 「レプリケーションのオプションと変数」をご確認ください。）このフィルタされたログはスレーブに提供されます。

ダミープロセスはデータの保存は行いませんので、レプリケーションマスタホストにmysqld プロセスを追加で実行させると、プロセスオーバーヘッドを被る事があります。このタイプのセットアップは追加のレプリケーションスレーブを使って繰り返す事ができます。

BLACKHOLEテーブルのINSERT トリガは予想通りに機能します。しかし、BLACKHOLE テーブルはデータの格納ができないので UPDATE と DELETE トリガは有効ではありません。行がないので、トリガ定義中の FOR ANY ROW 節は適用しません。

その他のBLACKHOLE ストレージエンジンの利用方法は次のようなものです。

MySQL 5.1.4にあるように、 実行されたトランザクションはバイナリログに書き込まれるが、ロールバックトランザクションは書き込まれない、という意味ではBLACKHOLE エンジンはトランザクション認識型です。