Arbeiten Sie mit eingeschaltetem Autocommit (der Standard), werden Änderungen an BDB-Tabellen sofort festgeschrieben (commit) und können nicht zurückgerollt werden.

Arbeiten Sie mit ausgeschaltetem Autocommit, werden die Änderungen erst permanent, nachdem Sie eine COMMIT-Anweisung ausgeführt haben. Stattdessen können Sie jedoch auch ein ROLLBACK ausführen, um die Änderungen zu widerrufen.

Eine Transaktion wird mit START TRANSACTION oder BEGIN gestartet, um den Autocommit-Modus implizit auszusetzen, oder mit SET AUTOCOMMIT=0, um den Autocommit-Modus explizit auszuschalten.

BDB-Tabellen können bis zu 31 Indizes pro Tabelle, 16 Spalten pro Index und 1024 Bytes pro Schlüssel haben.

MySQL erfordert einen Primärschlüssel in jeder BDB-Tabelle, um auf jede Zeile eindeutig verweisen zu können. Wenn Sie nicht explizit einenPRIMARY KEY deklarieren, erzeugt und wartet MySQL einen verborgenen Primärschlüssel. Dieser hat eine Länge von 5 Bytes und wird bei jedem Einfügeversuch um eins inkrementiert. Der Schlüssel erscheint nicht in der Ausgabe von SHOW CREATE TABLE oder DESCRIBE.

Der Primärschlüssel ist schneller als jeder andere Index, da er zusammen mit den Zeilendaten gespeichert wird. Da die anderen Indizes als Schlüsseldaten plus Primärschlüssel gespeichert werden, ist es wichtig, den Primärschlüssel möglichst kurz zu halten, um Plattenplatz zu sparen und eine höhere Geschwindigkeit zu erzielen.

Dieses Verhalten ist ähnlich wie das von InnoDB, wo kürzere Primärschlüssel nicht nur im Primärindex, sondern auch in den Sekundärindizes Platz sparen.

Wenn alle Spalten, auf die Sie in einer BDB-Tabelle zugreifen, zu demselben Index oder zum Primärschlüssel gehören, kann MySQL die Anfrage ausführen, ohne auf die eigentliche Zeile zugreifen zu müssen. In einer MyISAM-Tabelle ist dies nur möglich, wenn die Spalten zu demselben Index gehören.

Sequenzielles Scannen ist bei BDB-Tabellen langsamer als bei MyISAM-Tabellen, da die Daten in BDB-Tabellen in B-Bäumen und nicht in einer separaten Datendatei gespeichert werden.

Schlüsselwerte werden nicht Präfix- oder Suffix-komprimiert wie Schlüsselwerte in MyISAM-Tabellen. Mit anderen Worten: Die Schlüsselinformationen benötigen in BDB-Tabellen etwas mehr Platz als in MyISAM-Tabellen.

Oft gibt es Löcher in der BDB-Tabelle, damit Sie neue Zeilen in der Mitte des Schlüsselbaums einfügen können. Das macht BDB-Tabellen etwas größer als MyISAM-Tabellen.

SELECT COUNT(*) FROM tbl_name ist bei BDB-Tabellen langsam, da in der Tabelle kein Zeilenzähler gepflegt wird.

Der Optimierer muss näherungsweise die Anzahl von Zeilen in der Tabelle kennen. MySQL löst dieses Problem, indem Einfügeoperationen gezählt werden, und unterhält diese in einem separaten Segment in jeder BDB-Tabelle. Wenn Sie nicht viele DELETE- oder ROLLBACK-Anweisungen ausführen, sollte diese Zahl ausreichend genau für den MySQL-Optimierer sein. Da MySQL die Zahl nur beim Schließen speichert, kann sie falsch sein, wenn MySQL unerwartet beendet wird. Das sollte kein schwerer Fehler sein, selbst wenn die Zahl nicht zu 100% korrekt ist. Man kann die Anzahl von Zeilen aktualisieren, indem man ANALYZE TABLE oder OPTIMIZE TABLE ausführt. Siehe Abschnitt 13.5.2.1, „ANALYZE TABLE“ und Abschnitt 13.5.2.5, „OPTIMIZE TABLE“

Internes Sperren in BDB-Tabellen wird auf Seitenebene durchgeführt (page locking).

LOCK TABLES funktioniert bei BDB-Tabellen wie bei anderen Tabellen. Wenn Sie LOCK TABLES nicht benutzen, errichtet MySQL eine interne Sperre für Mehrfach-Schreibvorgänge auf der Tabelle (eine Sperre, die andere Schreibvorgänge nicht blockiert), um sicherzustellen, dass die Tabelle korrekt gesperrt ist, wenn ein anderer Thread eine Tabellensperre ausführt.

Um Transaktionen zurückrollen zu können, unterhält die BDB-Speicher-Engine Logdateien. Um maximale Performance zu erzielen, sollten Sie diese auf andere Festplatten platzieren als Ihre Datenbanken, indem Sie die Option --bdb-logdir verwenden.

MySQL macht jedes Mal, wenn eine neue BDB-Logdatei gestartet wird, einen Checkpoint und entfernt alle BDB-Logdateien, die nicht für aktuelle Transaktionen benötigt werden. Sie können auch jederzeit FLUSH LOGS laufen lassen, um einen Checkpoint für die Berkeley DB-Tabellen anzulegen.

Für die Wiederherstellung nach Abstürzen sollten Sie Datensicherungen der Tabellen plus das Binärlog von MySQL benutzen. Siehe Abschnitt 5.10.1, „Datenbank-Datensicherungen“.

Achtung: Wenn Sie alte Logdateien löschen, die noch in Gebrauch sind, ist BDB nicht in der Lage, Wiederherstellungen durchzuführen, und Sie könnten Daten verlieren, wenn etwas schief geht.

Die Anwendung muss stets darauf vorbereitet sein, Fälle zu handhaben, bei denen jegliche Änderung einer BDB-Tabelle zu einem automatischen Rollback führen kann und jegliches Lesen fehlschlagen kann, weil ein Deadlock auftritt.

Wenn die Platte bei einer BDB-Tabelle voll wird, wird ein Fehler gemeldet (wahrscheinlich Fehler 28) und die Transaktion sollte zurückgerollt werden. Im Gegensatz dazu wartet bei MyISAM-Tabellen der Server darauf, dass genügend Plattenplatz frei ist, ehe er fortfährt.