7.5 Tables InnoDB
7 Types de tables MySQL
Manuel de Référence MySQL 4.1 : Version Française
. Présentation des tables InnoDB
. Options de démarrage InnoDB
. Créer des bases InnoDB
. Créer des tables InnoDB
. Ajouter et retirer des données et des logs InnoDB
. Sauver et restaurer une base InnoDB
. Transférer une base de données InnoDB vers une autre machine
. Modèle transactionnel de InnoDB
->Implémentation du multi-versionnage
. Structures de tables et d'index
. Gestion de l'espace fichiers et des entrées/sorties disque
. Gestion des erreurs
. Restrictions sur les tables InnoDB
. Historique de l'évolution InnoDB
. Informations de contact InnoDB
|
7.5.9 Implémentation du multi-versionnage Comme InnoDB est une base de donnes multi-versionnée, elle doit conserver
des informations des vieilles versions des lignes dans l'espace de tables.
Cette information est stockée dans la structure de données que nous appelons
un segment d'annulation, d'après la structure similaire d'Oracle.
En interne, InnoDB ajoute deux champs à chaque ligne stockée dans
la base. Un champ de 6 octets note l'identifiant de la dernière transaction
qui a inséré ou modifier la ligne. De plus, un effacement est
traité en interne comme une modification, où un bit spécial dans la ligne
sert à marquer la ligne comme effacée. Chaque ligne contient aussi
une colonne de 7 octets appelé un pointeur d'annulation. Ce pointeur
fait référence à une ligne dans un fichier d'annulation qui contient
les informations nécessaires pour reconstruire le contenu de la ligne
qui a été modifiée.
InnoDB utilise les informations dans le segment d'annulation pour effectuer
les opérations d'annulation nécessaires dans une annulation de transaction.
Il utilise aussi ces informations pour reconstruire les anciennes
versions d'une ligne lors d'une lecture cohérente.
Le log d'annulation dans le segment d'annulation est divisé entre les
insertions et les modifications. Le log d'insertion n'est nécessaire que
lors des annulations de transactions, et peut être vidé dès que la requête
est validée. Le log de modification est utilisé lors des lectures
cohérentes, et les informations y sont supprimées une fois que toutes
les transactions qui font une lecture cohérente sont terminées.
Vous devez vous rappeler que valider vos transactions régulièrement,
même ces transactions qui ne font que des lectures cohérentes. Sinon,
InnoDB ne peut pas vider le log de modification, et le segment
d'annulation va grossir énormément.
La taille physique d'une ligne du log d'annulation dans le segment
d'annulation est typiquement plus petite que la ligne correspondante
insérée ou modifiée. Vous pouvez utiliser ces informations pour calculer
l'espace nécessaire à vos segments d'annulation.
Dans nos schémas de multi-versionnage, une ligne n'est pas physiquement
supprimée de la table immédiatement lorsque vous l'effacez avec une
requête SQL. Uniquement lorsque InnoDB va supprimer les lignes du
log de modification, il vaut aussi supprimer physiquement la ligne,
et les index. Cette opération d'effacement est appelée une purge, et elle
est plutôt rapide, et aussi rapide que la requête SQL elle-même.
|
