Tout d'abord, je pense qu'il serait utile comme arrière-plan de lire sur contrôle de concurrence multi-version (MVCC) en arrière-plan de cette réponse.
InnoDB implémente MVCC, ce qui signifie qu'il peut utiliser des lectures non bloquantes pour SELECT régulier . Cela ne nécessite pas de créer un "instantané" et en fait, InnoDB n'a pas de véritable concept d'instantané en tant qu'objet. Au lieu de cela, chaque enregistrement de la base de données garde une trace de son propre numéro de version et maintient un "pointeur de défilement" vers un enregistrement "journal d'annulation" (qui peut ou non encore exister) qui modifie la ligne à sa version précédente. Si une ancienne version d'un enregistrement est nécessaire, la version actuelle est lue et ces pointeurs de défilement sont suivis et annulent les enregistrements appliqués jusqu'à ce qu'une version suffisamment ancienne de l'enregistrement soit produite.
Normalement, le système nettoie constamment ces journaux d'annulation et réutilise l'espace qu'ils consomment.
À tout moment, n'importe quelle transaction de longue durée (notez qu'il ne s'agit pas nécessairement d'une seule requête) est présent, les journaux d'annulation doivent être conservés (et non purgés) afin de recréer suffisamment d'anciennes versions de tous les enregistrements pour satisfaire cette transaction. Dans un système très sollicité, ces journaux d'annulation peuvent s'accumuler très rapidement et consommer des gigaoctets d'espace. De plus, si des enregistrements individuels spécifiques sont très fréquemment modifiés, le rétablissement de cet enregistrement dans une version suffisamment ancienne pour satisfaire la requête peut nécessiter de très nombreuses applications de journal d'annulation (des milliers).
C'est ce qui rend les "requêtes de longue durée" coûteuses et mal vues. Ils augmenteront la consommation d'espace disque pour conserver les journaux d'annulation dans l'espace de table système, et ils fonctionneront mal en raison de l'application d'enregistrement de journal d'annulation pour annuler les versions de ligne lors de la lecture.
Certaines bases de données implémentent une quantité maximale d'espace de journal d'annulation pouvant être consommée, et une fois qu'elles ont atteint cette limite, elles commencent à jeter les anciens enregistrements de journal d'annulation et à invalider les transactions en cours d'exécution. Cela génère un message d'erreur "instantané trop ancien" pour l'utilisateur. InnoDB n'a pas une telle limite et permet l'accumulation indéfiniment.
