Si está ejecutando con autocommit activado (por defecto), los cambios en las tablas BDB se efectúan inmediatamente y no pueden deshacerse.

Si está ejecutando con autocommit desactivado, los cambios no son permanentes hasta que ejecuta un comando COMMIT . En lugar de hacer un commit puede ejecutar ROLLBACK para olvidar los cambios.

Puede comenzar una transacción con el comando BEGIN WORK para suspender autocommit, o con SET AUTOCOMMIT=0 para desactivar autocommit explícitamente.

En MySQL 5.0, las tablas BDB pueden tener hasta 31 índices por tabla, 16 columnas por índice, y un máximo de tamaño de clave de 1024 bytes.

MySQL necesita una PRIMARY KEY en cada tabla BDB para que cada registro pueda identificarse unívocamente. Si no crea una explícitamente, MySQL crea y mantiene una PRIMARY KEY oculta. La clave oculta tiene una longitud de 5 bytes y se incrementa para cada intento de inserción. Esta clave no aparece en la salida de SHOW CREATE TABLE o DESCRIBE.

La PRIMARY KEY es más rápida que cualquier otro índice, ya que la PRIMARY KEY se almacena junto con los datos. Los otros índices se almacenan como los datos claves + la PRIMARY KEY, por lo que es importante mantener la PRIMARY KEY tan pequeña como sea posible para ahorrar espacio en disco y tener más velocidad.

Este comportamiento es similar al de InnoDB, donde las claves primarias pequeñas ahorran espacio no sólo en el índice primario sino también en índices secundarios.

Si todas las columnas a las que accede en una tabla BDB son parte del mismo índice o parte de la clave primaria, MySQL puede ejcutar la consulta sin tener que acceder al registro. En una tabla MyISAM , esto sólo puede hacerse si las columnas son parte del mismo índice.

El escaneo secuencial es más lento que para tablas MyISAM ya que los datos en tablas BDB se almacena en B-trees y no en un fichero de datos separado.

Los valores clave no tienen compresión de prefijo ni sufijo como los valores clave en tablas MyISAM . En otras palabras, la información clave ocupa más espacio en tablas BDB en comparación con MyISAM .

A menudo hay huecos en la tabla BDB que le permiten insertar nuevos registros en medio del árbol índice. Esto hace que las tablas BDB sean algo más grandes que las MyISAM.

SELECT COUNT(*) FROM tbl_name es lento para tablas BDB , ya que no se mantiene conteo de registros en la tabla.

El optimizador necesita saber el número aproximado de registros en la tabla. MySQL resuelve esto contando inerciones y manteniendo esto en un segmento separado en cada tabla BDB . Si no realiza muchos comandos DELETE o ROLLBACK , este número debe ser lo bastante adecuado para el optimizador MySQL . Sin embargo, MySQL almacena el número sólo al cerrar, así que puede ser incorrecto si el servidor termina inesperadamente. Puede que no sea fatal incluso si este número no es 100% correcto. Puede actualizar el contador de registros usando ANALYZE TABLE o OPTIMIZE TABLE. Consulte Sección 13.5.2.1, “Sintaxis de ANALYZE TABLE” y Sección 13.5.2.5, “Sintaxis de OPTIMIZE TABLE”.

Bloqueo interno en tablas BDB se realiza a nivel de páginas.

LOCK TABLES funciona en tablas BDB como con otras tablas. Si no usa LOCK TABLES, MySQL realiza un bloqueo interno de múltiple escritura en la tabla (un bloqueo que no bloquea otros escritores) para asegurar que la tabla está bloqueada apropiadamente si otro flujo realiza un bloqueo de tabla.

Para poder deshacer transacciones, el motor de almacenamiento BDB mantiene ficheros de log. Para máximo rendimiento puede usar la opción --bdb-logdir para guardar los logs BDB en un disco distinto al que tiene las bases de datos.

MySQL realiza un checkpoint cada vez que se comienza un nuevo fichero log BDB , y borra cualquier fichero de log BDB no necesario para transacciones actuales. Puede usar FLUSH LOGS en cualquier momento para hacer un checkpoint de tablas Berkeley DB.

Para recuperación de desastres, debe usar copias de seguridad de tablas más el log binario de MySQL. Consulte Sección 5.8.1, “Copias de seguridad de bases de datos”.

Atención: Si borra ficheros de log antiguos que estén en uso, BDB no es capaz de recuperar todo y puede perder datos si algo no va bien.

Las aplicaciones deben estar siempre preparadas para tratar casos donde cualquier cambio en una tabla BDB pueda causar un rollback automático y cualquier lectura puede fallar con un error de deadlock.

Si obtiene un disco entero con una tabla BDB , obtiene un error (probablemente error 28) y la transacción debe deshacerse. Esto contrasta con tablas MyISAM en las que mysqld espera a tener más espacio libre para continuar.