Чтобы обеспечить возможность отката транзакций, для таблиц BDB поддерживается ведение файлов журналов. Для достижения максимальной производительности эти файлы необходимо разместить на разных с базой данных дисках, воспользовавшись параметром --bdb-logdir.

Каждый раз, когда создается новый файл журнала BDB, MySQL устанавливает контрольные точки и удаляет все файлы журналов, которые не нужны для текущих транзакций. Можно также в любое время запустить команду FLUSH LOGS, чтобы установить контрольную точку для таблиц Berkeley DB. Чтобы произвести восстановление после сбоя, необходимо воспользоваться резервными копиями таблицы, а также бинарным журналом MySQL (see Раздел 4.4.1, «Резервное копирование баз данных»). Предупреждение: если удалить используемые старые файлы журналов, BDB не сможет осуществить восстановление, и в случае сбоя вы можете потерять данные.

В MySQL все таблицы BDB должны иметь первичные ключи, чтобы обеспечить возможность обращаться к ранее считанным строкам. Если первичный ключ не создан, MySQL создаст его и будет поддерживать скрытый первичный ключ. Длина скрытого ключа составляет 5 байтов, а его значение увеличивается при каждой попытке вставки.

Если все столбцы, к которым производится обращение в таблице BDB, являются частью одного индекса или одного первичного ключа, то MySQL может выполнить запрос, не обращаясь к самой строке. Для таблиц MyISAM это справедливо только если столбцы являются частью одного индекса.

Первичный ключ обеспечивает более быструю обработку, чем любой другой ключ, так как он хранится вместе с данными строки. Поскольку остальные ключи хранятся как данные ключа + PRIMARY KEY, очень важно иметь как можно более короткие первичные ключи, чтобы сэкономить дисковое пространство и увеличить производительность.

Команда LOCK TABLES работает с таблицами BDB точно так же, как и с другими таблицами. Если команда LOCK TABLE не используется, MySQL устанавливает на таблицу внутреннюю множественную блокировку записи, чтобы обеспечить правильную блокировку, если другой поток установит блокировку таблицы.

Внутренняя блокировка в таблицах BDB осуществляется на уровне страниц.

Команда SELECT COUNT(*) FROM table_name выполняется медленно, так как для таблиц BDB не поддерживается подсчет количества строк в таблице.

Сканирование осуществляется медленнее, чем в таблицах MyISAM, так как данные в таблицах BDB хранятся в B-деревьях, а не в отдельных файлах данных.

Приложение всегда должно быть готово к обработке ситуаций, в которых любые изменения таблицы BDB могут привести к автоматическому откату и любое считывание может вызвать сбой из-за возникновения взаимоблокировки.

Ключи не являются пакованными как в MyISAM. Иначе говоря, информация по ключам в таблицах BDB займет несколько больше места по сравнению с таблицами MyISAM.

В таблице BDB всегда имеются промежутки, благодаря чему можно вставлять новые строки в середину дерева ключа. Из-за этого таблицы BDB несколько больше, чем таблицы MyISAM.

Оптимизатору необходимо знать приблизительное количество строк в таблице. В MySQL этот вопрос решается путем подсчета количества вставок и поддержки этой информации в отдельном сегменте каждой таблицы BDB. Если операторов DELETE или ROLLBACK выполнялось не слишком много, это количество должно быть достаточно точным для оптимизатора MySQL, но MySQL сохраняет это число только при закрытии, и оно в случае аварийного завершения работы MySQL может оказаться неверным. Если число не соответствует действительности на 100% - ничего страшного в этом нет. Количество строк можно обновить, запустив команду ANALYZE TABLE или OPTIMIZE TABLE (см. разделы Раздел 4.5.2, «Синтаксис команды ANALYZE TABLE » и see Раздел 4.5.1, «Синтаксис команды OPTIMIZE TABLE »).

Если таблица BDB займет все пространство на диске, то будет выведено сообщение об ошибке (возможно, ошибка 28) и выполнен откат транзакции. В отличие от BDB, таблицы MyISAM и ISAM в mysqld будут ожидать, пока не появится свободное место, а потом продолжат работу.