Verrou de clé suivante : éviter le problème des lignes fantômes
<<<		 Un exemple de lecture cohérente avec InnoDB Les verrous posés par différentes requêtes SQL avec InnoDB
>>>
16.11 Modèle de transactions et verrouillage InnoDB
16 Tables InnoDB
 Manuel de Référence MySQL 4.1 : Version Française
. InnoDB et AUTOCOMMIT
. InnoDB et SET ... TRANSACTION ISOLATION LEVEL ...
. Lecture cohérente non-bloquante
. Verrous de lecture SELECT ... FOR UPDATE et SELECT ... LOCK IN SHARE MODE
. Verrou de clé suivante : éviter le problème des lignes fantômes
->Un exemple de lecture cohérente avec InnoDB
. Les verrous posés par différentes requêtes SQL avec InnoDB
. Quand est-ce que MySQL valide ou annule implicitement une transaction?
. Détection des blocages et annulation
. Comment gérer les blocages de verrous?

16.11.6 Un exemple de lecture cohérente avec InnoDB

Supposons que vous exécutez MySQL avec le niveau d'isolation des transactions de REPEATABLE READ . Lorsque vous demandez une lecture cohérente avec une commande SELECT ordinaire, InnoDB va donner à votre transaction une date jalon, en fonction de laquelle votre requête va voir la base. Ainsi, si une transaction B efface une ligne après l'assignation de ce jalon, vous ne verrez pas cette ligne. De même pour une insertion ou une modification.

Vous pouvez faire avancer votre date jalon en validant votre transaction et en exécutant un autre SELECT .

Cela s'appelle le contrôle simultané multi-versions. 

User A                 User B
 
              SET AUTOCOMMIT=0;      SET AUTOCOMMIT=0;
time
|             SELECT * FROM t;
|             empty set
|                                    INSERT INTO t VALUES (1, 2);
|
v             SELECT * FROM t;
              empty set
                                     COMMIT;
 
              SELECT * FROM t;
              empty set;
 
              COMMIT;
 
              SELECT * FROM t;
              ---------------------
              |    1    |    2    |
              ---------------------
De cette façon, A voir la ligne insérée par B uniquement lorsque B a validé son insertion, et que A a validé sa propre transaction, de façon à ce que la date jalon soit plus récente que la validation de B.Si vous voulez avoir une vision aussi ``fraîche'' que possible de votre base, vous devez utiliser le verrou en lecture : 

SELECT * FROM t LOCK IN SHARE MODE;

<< Un exemple de lecture cohérente avec InnoDB >>
Verrou de clé suivante : éviter le problème des lignes fantômes Modèle de transactions et verrouillage InnoDB Les verrous posés par différentes requêtes SQL avec InnoDB