Para estar apto a fazer roolback da transação, o mecanismo de armazenamento BDB mantém arquivos de log. Para obter o máximo de desempenho você deve colocar estes arquivos em outro disco diferente do usado por seus bancos de dados usando a opção --bdb-logdir.

O MySQL realiza um ponto de verificação a cada vez que um novo arquivo de log do BDB é iniciado e remove qualquer arquivo de log que não for necessário para a transação atual. Pode se executar FLUSH LOGS a qualquer momento para faze um ponto de verificação de tabelas Berkeley DB.

Para recuperação de desastres, deve-se usar backups de tabelas mais log binário do MySQL. See Secção 4.5.1, “Backups dos Bancos de Dados”.

Aviso: Se você delatar arquivos de log antigos que estão em uso, o BDB não estará apto a fazer a recuperação e você pode perder dados se algo der errado.

O MySQL precisa de uma PRIMARY KEY em cada tabela BDB para poder fazer referência a linha lida anteriormente. Se você não criar um o MySQL criará uma chave primária oculta para você. A chave oculta tem um tamanho de 5 bytes e é incrementada a cada tentaiva de inserção.

Se todas as colunas que você acessa em uma tabela BDB são parte do mesmo índice ou parte de uma chave primária, então o MySQL pode executar a consulta ser ter que acessar a linha atual. Em uma tabela MyISAM o descrito acima é guardado apenas se as colunas são parte do mesmo índice.

A PRIMARY KEY será mais rápida que qualquer outra chave, já que a PRIMARY KEY é armazenada junto com o registro do dado. Como as outras chaves são armazenads como os dados da chave + a PRIMARY KEY, é importante manter a PRIMARY KEY o menor possível para economizar disco e conseguir maior velocidade.

LOCK TABLES funciona em tabelas BDB como nas outras tabelas. Se você não utilizar LOCK TABLE, MySQL comandará um bloqueio interno de múltipla-escrita nas tabelas para assegurar que a tabela será bloqueada apropriadamente se outra thread executar um bloqueio de tabela.

Bloqueios internos em tabelas BDB é feito por página.

SELECT COUNT(*) FROM nome_tabela é lento pois tabelas BDB não mantém um contador do número de linha na tabela.

A varredura sequencial é mais lenta que com tabelas MyISAM já que os dados em tabelas BDB são armazenados em árvores-B e não em um arquivo de dados separado.

A aplicação sempre deve estar preparada para tratar casos onde qualquer alteração de uma tabela BDB pode fazer um rollback automático e quqlquer leitura pode falhar com um erro de deadlock.

As chaves não são compactadas por prefixo ou por sufixo como em tabelas MyISAM. Em outras palavras, a informação da chave gastará um pouco mais de espaço em tabelas BDB quando comparadas a tabelas MyISAM.

Existem buracos frequentemente em tabelas BDB para permitir que você insira novas linhas no meio da árvore de chaves. Isto torna tabelas BDB um pouco maiores que tabelas MyISAM.

O otimizador precisa conhecer aproximadamente o número de linhas na tabela. O MySQL resolve isto contando inserções e mantendo isto em um segmento separado em cada tabela BDB. Se você não executar várias instruções DELETE ou ROLLBACK, este número deverá estar suficientemente próximo do exato para o otimizador do MySQL, mas como o MySQL só armazerna o número ao finalizar, ele pode estar incorreto se o MySQL finalizar inesperadamente. Isto não deve ser fatail mesmo se este número não for 100% correto. POde se atualizar o número de linhas executando ANALYZE TABLE ou OPTIMIZE TABLE. See Secção 4.6.2, “Sintaxe de ANALYZE TABLE” . See Secção 4.6.1, “Sintaxe de OPTIMIZE TABLE”.

Se você ficar com o seu disco cheio com uma tabela BDB, você obterá um erro (provavelmente erro 28) e deve ser feito um rollback da transação. Isto está em contraste com as tabelas MyISAM e ISAM onde o mysqld irá esperar por espaço suficiente em disco pra continuar.