Concepts et caractéristiques des transactions de base de données
Une transaction de base de données est un mécanisme, une séquence d'opérations et comprend un ensemble de commandes d'opération de base de données. Une transaction soumet ou révoque une demande d'opération au système avec toutes les commandes dans leur ensemble, c'est-à-dire que cet ensemble de commandes de base de données est soit exécuté, soit non exécuté, la transaction est donc une unité de travail logique indivisible.
Lors de l'exécution d'opérations simultanées sur un système de base de données, les transactions sont utilisées comme la plus petite unité de contrôle, ce qui est particulièrement adapté aux systèmes de bases de données exploités par plusieurs utilisateurs en même temps. Par exemple, les systèmes de réservation des compagnies aériennes, les banques, les compagnies d'assurance et les systèmes de négociation de titres.
Les transactions ont quatre caractéristiques, à savoir l'atomicité, la cohérence, l'isolement et la durabilité, ces quatre caractéristiques sont généralement appelées ACID.
1. Atomicité
Une transaction est une opération complète. Les éléments d'une transaction sont indivisibles (atomiques). Tous les éléments de la transaction doivent être validés ou annulés dans leur ensemble. Si un élément de la transaction échoue, la transaction entière échoue.
En prenant comme exemple la transaction de virement bancaire, si la transaction est soumise, les données des deux comptes seront mises à jour. Si, pour une raison quelconque, la transaction se termine avant la mise à jour réussie des deux comptes, les soldes des deux comptes ne seront pas mis à jour, les modifications apportées aux soldes des comptes seront annulées et la transaction ne pourra pas être partiellement validée.
2. Cohérence
Une fois la transaction terminée, les données doivent être dans un état cohérent. Autrement dit, les données stockées dans la base de données sont dans un état cohérent avant le début de la transaction. Lors d'une transaction en cours, les données peuvent être dans un état incohérent, par exemple, les données peuvent être partiellement modifiées. Cependant, lorsque la transaction se termine avec succès, les données doivent à nouveau être renvoyées à un état cohérent connu. Les modifications apportées aux données via des transactions ne peuvent pas endommager les données, ou les transactions ne peuvent pas laisser le stockage des données dans un état instable.
Prenons l'exemple de la transaction de virement bancaire. Avant le début de la transaction, le total de tous les soldes des comptes est dans un état cohérent. Au cours de la transaction, le solde d'un compte est réduit, tandis que le solde de l'autre compte n'a pas été modifié. Par conséquent, le total de tous les soldes des comptes est incohérent. Une fois la transaction terminée, le solde total du compte est à nouveau rétabli dans un état cohérent.
3. Isolement
Toutes les transactions simultanées qui modifient les données sont isolées les unes des autres, ce qui signifie que les transactions doivent être indépendantes et ne doivent en aucun cas dépendre ou affecter d'autres transactions. Une transaction qui modifie des données peut accéder aux données avant le début d’une autre transaction utilisant les mêmes données ou après la fin d’une autre transaction utilisant les mêmes données.
De plus, lorsqu'une transaction modifie des données, si un autre processus utilise les mêmes données en même temps, les modifications apportées aux données ne prendront effet que lorsque la transaction sera validée avec succès. Le transfert entre Zhang San et Li Si et le transfert entre Wang Wu et Zhao Er sont toujours indépendants l'un de l'autre.
4. Durabilité
La durabilité des transactions signifie que, quelle que soit la défaillance du système, les résultats du traitement des transactions sont permanents.
Une fois qu'une transaction est terminée avec succès, les modifications apportées à la base de données sont permanentes, même en cas de panne du système. C'est-à-dire qu'une fois la transaction validée, toute modification apportée aux données par la transaction sera conservée en permanence dans la base de données.
Le principe ACID des transactions garantit qu'une transaction est soit validée avec succès, soit échouée et annulée, ou l'un des deux. Ses modifications apportées à la transaction sont donc récupérables. Autrement dit, lorsqu'une transaction échoue, ses modifications de données seront restaurées à l'état où elles étaient avant l'exécution de la transaction.
Syntaxe et processus d'exécution des transactions MySQL
MySQL fournit plusieurs moteurs de stockage pour prendre en charge les transactions. Les moteurs de stockage qui prennent en charge les transactions incluent InnoDB et BDB. Les transactions du moteur de stockage InnoDB sont principalement implémentées via les journaux UNDO et REDO. Le moteur de stockage MyISAM ne prend pas en charge les transactions.
Expansion : tout type de base de données disposera de divers journaux pour enregistrer l'état d'exécution, les opérations quotidiennes, les messages d'erreur, etc. de la base de données, et MySQL ne fait pas exception. Par exemple, lorsque l'utilisateur root se connecte au serveur MySQL, l'heure de connexion de l'utilisateur, les opérations d'exécution, etc. seront enregistrées dans le fichier journal.
Afin de maintenir le serveur MySQL, il est souvent nécessaire d'effectuer des opérations de journalisation dans la base de données MySQL :
- Journal UNDO : copie les données avant l'exécution de la transaction et est utilisé pour restaurer les données lorsqu'une exception se produit dans la transaction.
- Journal REDO : enregistre chaque opération qui met à jour les données pendant l'exécution de la transaction. Lorsque la transaction est validée, le contenu sera vidé sur le disque.
Compétences de base de la base de données Mysql pratique complète 
https://edu.csdn.net/course/detail/36210
Sous les paramètres par défaut, chaque instruction SQL est une transaction, c'est-à-dire qu'elle est automatiquement soumise après l'exécution de l'instruction SQL. Afin de combiner plusieurs opérations dans leur ensemble, vous devez utiliser BEGIN ou START TRANSACTION pour démarrer une transaction, ou désactiver la soumission automatique de la session en cours.
Pour plus d'informations sur la soumission automatique des transactions, vous pouvez lire la section « Paramètres MySQL de soumission automatique des transactions ».
Syntaxe et processus d'exécution des transactions
SQL utilise les instructions suivantes pour gérer les transactions.
1) Démarrer la transaction
BEGIN;ou
START TRANSACTION;Cette déclaration marque explicitement le point de départ d'une transaction.
2) Soumettre la transaction
MySQL utilise l'instruction suivante pour valider une transaction :
COMMIT;COMMIT signifie valider une transaction, c'est-à-dire valider toutes les opérations de la transaction. Plus précisément, toutes les mises à jour de la base de données dans la transaction sont écrites dans la base de données physique sur le disque et la transaction se termine normalement.
Valider une transaction signifie que toutes les données exécutées depuis le début de la transaction seront modifiées et deviendront une partie permanente de la base de données, marquant ainsi également la fin d'une transaction. Une fois cette commande exécutée, la transaction ne peut pas être annulée. Cette opération est effectuée uniquement lorsque toutes les modifications sont prêtes à être validées dans la base de données.
3) Annuler (annuler) la transaction
MySQL annule la transaction à l'aide de l'instruction suivante :
ROLLBACK;ROLLBACK signifie annuler la transaction, c'est-à-dire qu'une sorte d'échec se produit pendant l'exécution de la transaction et que la transaction ne peut pas continuer à être exécutée. Le système annulera toutes les opérations terminées sur la base de données dans la transaction et reviendra à l'état du début. de la transaction. L'opération fait ici référence à l'opération de mise à jour sur la base de données.
Lorsqu'une erreur survient lors de l'exécution d'une transaction, utilisez l'instruction ROLLBACK pour restaurer la transaction au point de départ ou à un point d'arrêt spécifié. Dans le même temps, le système effacera toutes les modifications de données apportées depuis le point de départ de la transaction ou jusqu'à un certain point de sauvegarde, et libérera les ressources contrôlées par la transaction. Cette déclaration marque donc également la fin de la transaction.
Résumer
Les opérations de mise à jour des données de la base de données par les instructions SQL suivant l'instruction BEGIN ou START TRANSACTION seront enregistrées dans le journal des transactions jusqu'à ce que l'instruction ROLLBACK ou COMMIT soit rencontrée. Si une opération dans la transaction échoue et qu'une instruction ROLLBACK est exécutée, toutes les données mises à jour après l'ouverture de l'instruction de transaction peuvent être restaurées à l'état avant le démarrage de la transaction. Si toutes les opérations de la transaction sont terminées correctement et que l'instruction COMMIT est utilisée pour soumettre des données mises à jour à la base de données, les données se trouvent à ce moment dans un nouvel état cohérent.
Exemple de démonstration
Vous trouverez ci-dessous deux exemples pour démontrer l'utilisation spécifique des transactions MySQL.
Exemple 1
Ce qui suit simule le scénario dans lequel d'autres sessions accèdent à la table de données après que le compte de Zhang San ait diminué de 500 yuans, mais que le compte de Li Si n'ait pas augmenté de 500 yuans. Puisque le code doit être exécuté dans deux fenêtres, pour faciliter la lecture, nous les appelons ici fenêtre A et fenêtre B.
1) Ouvrez une transaction dans la fenêtre A et mettez à jour les données de la table bancaire dans la base de données mybank. L'instruction SQL et les résultats d'exécution sont les suivants :
mysql> USE mybank;
Database changed
mysql> BEGIN;
Query OK, 0 rows affected (0.00 sec)
mysql> UPDATE bank SET currentMoney = currentMoney-500
-> WHERE customerName='张三';
Query OK, 1 row affected (0.05 sec)
Rows matched: 1 Changed: 1 Warnings: 02) Recherchez les données dans la table de données bancaires de la fenêtre B. L'instruction SQL et les résultats d'exécution sont les suivants :
mysql> SELECT * FROM mybank.bank;
+--------------+--------------+
| customerName | currentMoney |
+--------------+--------------+
| 张三 | 1000.00 |
| 李四 | 1.00 |
+--------------+--------------+
2 rows in set (0.00 sec)Les résultats montrent que bien que la transaction dans la fenêtre A ait modifié les données de la table bancaire, les données ne sont pas mises à jour immédiatement.À ce stade, d'autres sessions lisent encore les données avant la mise à jour.
3) Continuez à exécuter la transaction dans la fenêtre A et soumettez la transaction. L'instruction SQL et les résultats d'exécution sont les suivants :
mysql> UPDATE bank SET currentMoney = currentMoney+500
-> WHERE customerName='李四';
Query OK, 1 row affected (0.05 sec)
Rows matched: 1 Changed: 1 Warnings: 0
mysql> COMMIT;
Query OK, 0 rows affected (0.07 sec)4) Interrogez à nouveau les données de la table de données bancaires dans la fenêtre B. L'instruction SQL et les résultats d'exécution sont les suivants :
mysql> SELECT * FROM mybank.bank;
+--------------+--------------+
| customerName | currentMoney |
+--------------+--------------+
| 张三 | 500.00 |
| 李四 | 501.00 |
+--------------+--------------+
2 rows in set (0.00 sec)Après avoir exécuté COMMIT pour valider la transaction dans la fenêtre A, les mises à jour des données seront soumises ensemble et les autres sessions liront les données mises à jour. Il ressort des résultats que le solde total des comptes de Zhang San et Li Si reste cohérent avec celui d'avant le transfert, de sorte que les données sont mises à jour d'un état de cohérence à un autre.
Comme mentionné précédemment, lorsqu'un problème survient lors de l'exécution d'une transaction, c'est-à-dire lorsqu'une transaction complète ne peut pas être exécutée selon le processus normal, vous pouvez utiliser l'instruction ROLLBACK pour revenir en arrière et utiliser les données pour restaurer l'état initial.
Dans l'exemple 1, le solde du compte de Zhang San a été réduit à 500 yuans. Si 1 000 yuans supplémentaires sont transférés, le solde sera négatif, il devra donc être ramené à son état d'origine. Comme le montre l'exemple 2.
Exemple 2
Réduisez le solde du compte de Zhang San de 1 000 yuans et annulez la transaction. L'instruction SQL et les résultats d'exécution sont les suivants :
mysql> BEGIN;
Query OK, 0 rows affected (0.00 sec)
mysql> UPDATE bank SET currentMoney = currentMoney-1000 WHERE customerName='张三';
Query OK, 1 row affected (0.04 sec)
Rows matched: 1 Changed: 1 Warnings: 0
mysql> ROLLBACK;
Query OK, 0 rows affected (0.07 sec)
mysql> SELECT * FROM mybank.bank;
+--------------+--------------+
| customerName | currentMoney |
+--------------+--------------+
| 张三 | 500.00 |
| 李四 | 501.00 |
+--------------+--------------+
2 rows in set (0.00 sec)Il ressort des résultats qu'après l'exécution de l'annulation de la transaction, les données du compte sont restaurées à leur état initial, c'est-à-dire l'état avant l'exécution de la transaction.
développer
Dans les opérations de base de données, afin de garantir efficacement l'exactitude des données lues simultanément, le niveau d'isolation des transactions est proposé. Dans les démonstrations de l'exemple 1 et de l'exemple 2, le niveau d'isolement de la transaction est le niveau d'isolement par défaut. Dans MySQL, le niveau d'isolement par défaut d'une transaction est le niveau d'isolement REPEATABLE-READ (lisible), c'est-à-dire que lorsque la transaction n'est pas terminée (COMMIT ou ROLLBACK n'est pas exécuté), les autres sessions ne peuvent lire que les données non validées.
Veuillez cliquer sur Niveaux d'isolation des transactions MySQL pour en savoir plus.
Précautions
La transaction MySQL est une fonction très gourmande en ressources, vous devez faire attention aux points suivants lorsque vous l'utilisez.
1) Gardez les transactions aussi courtes que possible
Du début à la fin d'une transaction, une grande quantité de ressources sera réservée dans le système de gestion de base de données pour assurer l'atomicité, la cohérence, l'isolement et la durabilité de la transaction. Dans un système multi-utilisateurs, les transactions volumineuses occuperont une grande quantité de ressources système, ce qui saturera le système, affectera les performances d'exécution du logiciel et provoquera même un crash du système.
2) La quantité de données accessibles lors de la transaction doit être minimisée.
Lorsque les transactions sont exécutées simultanément, plus la quantité de données sur laquelle la transaction opère est petite, moins il y a d'opérations sur les mêmes données entre les transactions.
3) Essayez de ne pas utiliser de transactions lors de l'interrogation de données
La navigation et l'interrogation des données ne mettront pas à jour les données de la base de données, vous devez donc essayer de ne pas utiliser de transactions pour interroger les données afin d'éviter d'occuper des ressources système excessives.
4) Essayez de ne pas attendre la saisie de l'utilisateur pendant le traitement de la transaction.
Pendant le traitement de la transaction, si vous devez attendre que l'utilisateur saisisse des données, la transaction occupera des ressources pendant une longue période et peut provoquer une congestion du système.