BDB ストレージエンジンは、トランザクションをロールバックできるようにログファイルを保持している。パフォーマンスを最大限に高めるには、--bdb-logdir オプションを使ってこれらのログファイルをデータベースとは別のディスクに配置する必要がある。

MySQL は、新しい BDB ログファイルが開始されるたびにチェックポイントを実行し、現在のトランザクションに不要なログファイルを削除する。FLUSH LOGS を任意の時点で実行して、Berkeley DB テーブルをチェックポイントすることもできる。

障害リカバリには、テーブルバックアップおよび MySQL のバイナリログを使用する必要がある。 See 項4.5.1. 「データベースのバックアップ」。

警告: 使用中の古いログファイルを削除すると、問題が発生した場合に BDB がリカバリを実行できなくなり、データが失われるおそれがある。

MySQL は、前に読み取られたレコードを参照できるように、各 BDB テーブルに主キーを必要とする。ユーザがこのキーを作成しない場合は、MySQL によって隠し主キーが作成され、管理される。この隠しキーは長さが 5 バイトで、挿入が試行されるたびにインクリメントされる。

BDB テーブルでアクセスするすべてのカラムが、同じインデックスの一部または主キーの一部であれば、MySQL は実際のレコードにアクセスすることなくクエリを実行できる。MyISAM テーブルでは、カラムが同じインデックスの一部である場合のみこれが当てはまる。

主キーは、ローデータと共に格納されるため、他のどのキーよりも速く処理される。他のキーはキーデータ + 主キーとして格納されるため、主キーはできるだけ短くしてディスクを節約し、処理速度を高めることが重要である。

LOCK TABLES は、他のテーブルと同様に BDB テーブルでも動作する。LOCK TABLE を使用しない場合は、MySQL によってテーブルに対する内部的な複数書き込みのロックが発行され、別のスレッドがテーブルロックを発行した場合にテーブルが適切にロックされるようになる。

BDB テーブルでの内部ロックは、ページレベルで行われる。

BDB テーブルではテーブル内のレコード数のカウントが管理されないため、SELECT COUNT(*) FROM table_name に時間がかかる。

BDB テーブルのデータは、独立したデータファイルではなく B ツリーに格納されるため、順次スキャンには MyISAM テーブルよりも時間がかかる。

アプリケーションでは、BDB テーブルの変更で発生する自動ロールバックおよびデッドロックエラーを伴う読み取りの失敗にいつでも対処できるようにしておく必要がある。

MyISAM テーブルのキーとは異なり、キーのプリフィックスまたはサフィックスは圧縮されない。つまり、BDB テーブルでは MyISAM テーブルに比べてキー情報の領域が若干大きい。

BDB テーブルには、多くの場合、キーツリーの途中で新たなレコードを挿入できるようにすき間が空いている。このため、BDB テーブルは MyISAM テーブルよりも若干大きくなる。

オプティマイザには、テーブル内のおおよそのレコード数を通知する必要がある。MySQL は、挿入の回数をカウントし、その数値を BDB テーブル内の独立したセグメントで管理することで、これに対応している。DELETE または ROLLBACK ステートメントを大量に発行しない限り、この数値は MySQL オプティマイザにとって十分に正確であるが、MySQL はクローズ時までこの数値を格納しないため、MySQL が突然中断されると数値が不正確になる場合がある。この数値が 100% 正確でなくても、致命的な問題にはならない。レコードの数は、ANALYZE TABLE または OPTIMIZE TABLE を実行することで更新できる。 See 項4.6.2. 「ANALYZE TABLE 構文」。 See 項4.6.1. 「OPTIMIZE TABLE 構文」。

BDB テーブルでディスクがいっぱいになると、エラー（おそらくエラー 28）が発生し、トランザクションがロールバックされる。これとは対照的に、MyISAM テーブルと ISAM テーブルでは、十分な空きディスクが確保されるのを待って、mysqld が処理を続行する。