7.6.4 Caractéristiques des tables BDB

• Pour permettre les transactions annulabes, BDB gère un fichier de log. Pour maximiser les performances, vous devriez placer ces fichiers sur un autre disque que celui de votre base, en utilisant l'option --bdb-logdir .
• MySQL fait un point de contrôle à chaque fois qu'un nouveau fichier de log BDB est démarré, et supprime les fichiers de logs anciens qui ne sont pas utiles. Si vous exécutez la commande FLUSH LOGS , vous placerez un nouveau point de contrôle pour les tables Berkeley DB.Pour la restauration après crash, vous devez utiliser les sauvegardes et le log binaire de MySQL. Sauvegardes de base de données . Attention : si vous effacez les anciens fichiers de log qui sont en cours d'utilisation, BDB ne sera pas capable de faire la restauration et vous risquez de perdre des données.
• MySQL requiert une clé PRIMARY KEY dans chaque table BDB pour être capable de faire référence aux lignes précédemment lues. Si vous n'en créez pas, MySQL va gérer une telle clé de manière cachée. La clé cachée a une taille de 5 octets, et est incrémentée à chaque nouvelle insertion.
• Si toutes les colonnes auxquelles vous accédez dans une table BDB font parties du même index dans la clé primaire, alors MySQL peut exécuter la requête sans avoir à lire la ligne elle-même. Dans une table MyISAM , ce qui précède n'est valable que si les colonnes font partie du même index.
• La clé PRIMARY KEY sera plus rapide que n'importe quelle autre clé, car la PRIMARY KEY est stockée avec les données. Comme les autres clés sont stockées sous la forme données + PRIMARY KEY , il est important de garder une clé PRIMARY KEY aussi courte que possible pour économiser de l'espace disque, et améliorer la vitesse.
• LOCK TABLES fonctionne avec les tables BDB sur les autres tables. Si vous n'utilisez pas le verrou LOCK TABLE , MySQL va poser un verrou interne multiple sur la table, pour s'assurer que la table est bien verrouillée, si un autre thread tente de poser un verrou.
• Le verrouillage interne des tables BDB est fait au niveau page.
• SELECT COUNT(*) FROM table_name est très lent, car les tables BDB ne maintiennent pas un compte de leur lignes dans la table.
• Scanner est plus lent qu'avec MyISAM car les tables BDB stockent les données dans un fichier B-tree et non pas dans un fichier séparé.
• L'application doit toujours être prête à gérer des cas où une modification sur une table BDB peut être annulée, ou une lecture abandonnée pour cause de blocage de verrous.
• Les clés ne sont pas compressées avec les clés précédentes, comme pour les tables ISAM et MyISAM . En d'autres termes, les informations de clés prennent un peu plus d'espace pour les tables BDB , comparativement aux tables MyISAM qui n'utilisent pas l'option PACK_KEYS=0 .
• Il y a souvent des trous dans les tables BDB pour vous permettre d'insérer de nouvelles lignes au milieu de l'arbre de données. Cela rend les tables BDB un peu plus grandes que les tables MyISAM .
• L'optimiseur a besoin de connaître une approximation du nombre de lignes dans la table. MySQL résoud ce problème en comptant les insertions et en conservant ce compte dans un segment séparé pour chaque table BDB . Si vous ne faites pas souvent de DELETE ou ROLLBACK , ce nombre sera plutôt précis pour l'optimiseur MySQL, mais comme MySQL ne stocke ce nombre qu'à la fermeture de la table, il peut être incorrecte si MySQL crashe. Cela ne doit pas être fatal si ce nombre n'est pas à 100% correct. Vous pouvez forcer la mise à jour de ce nombre avec la commande ANALYZE TABLE ou OPTIMIZE TABLE . Syntaxe de ANALYZE TABLE . Syntaxe de OPTIMIZE TABLE .
• Si vous atteignez la capacité maximale du disque avec la table BDB , vous allez obtenir une erreur (probablement l'erreur 28), et la transaction va s'annuler. C'est un comportement différent des tables MyISAM et ISAM qui vont attendre que mysqld ait trouvé de l'espace disque avant de continuer.