Re-compréhension des transactions de base de données MYSQL

Le concept de transaction : une série d'opérations effectuées par une seule unité logique de travail, soit complètement, soit pas du tout. Une compréhension simple est que chaque opération sur les données est effectuée dans l’unité de travail logique de la transaction.

Les quatre propriétés des transactions : ACIDE.

A : atomique, atomicité. L'atomicité met l'accent sur l'indivisibilité et résume le processus d'exécution de la base de données en un objet entité. Ensuite, cet objet existe ou n'existe pas. Lorsqu'il est exécuté, soit l'ensemble du processus est terminé, soit il n'est pas exécuté.

Cet avantage garantit l'intégrité et l'exactitude des données. L'exemple le plus réel est que la même carte bancaire se brise soudainement pendant le processus de transfert, et la transaction ne peut pas être finalisée et est annulée. Enfin, assurez-vous que les données sont dans leur état d'origine afin que le solde de votre carte ne soit pas réduit.

C : Cohérent. La compréhension de la cohérence et de l'atomicité est fondamentalement la même, et les deux visent à garantir l'intégrité des données. Par exemple, une transaction est composée de quatre opérations : ajout, suppression, modification et requête uniquement lorsque les quatre opérations sont exécutées. avec succès, il peut rester un statut de succès, tant qu'une opération ne parvient pas à s'exécuter, il s'agit d'un statut d'échec, garantissant l'unité du statut.

I : Isolation, Isolation. L'isolement existe pour les transactions simultanées. Toutes les transactions sont isolées les unes des autres et ne s'affectent pas. Dans le cas d'un isolement élevé, lorsqu'une transaction accède à une autre transaction, elle accède soit à l'état avant l'exécution de la transaction, soit à l'état après la fin de l'exécution. Elle n'accède pas à l'état entre l'exécution de la première transaction, mais cela conduit. à la simultanéité des données. Pour réduire le niveau d’isolement des transactions, toutes les transactions doivent être pondérées en fonction des exigences réelles lors de la conception de la base de données.

L'isolement des transactions peut être divisé du moins profond au plus profond : READ UNCOMMITTED (lecture non validée)---READ COMMITTED (lecture validée)---REPEATABLE READ (lecture répétable)- - -SERIALIZABLE (Sérialisation)

(1) SERIALIZABLE (Sérialisation)

Ajouter des verrous de plage (tels que des verrous de table, des verrous de page, etc. , je n'ai fait aucune recherche approfondie sur le verrouillage de plage) jusqu'à la fin de la transaction A. Cela empêche les autres transactions B d'insérer, de mettre à jour et d'autres opérations dans cette plage.
Les problèmes tels que les lectures fantômes, les lectures sales et les lectures non répétables ne se produiront pas.

(2) REPEATABLE READ (lecture répétable)

Pour les enregistrements lus, ajoutez un verrou partagé jusqu'à la fin de la transaction A . Les tentatives des autres transactions B pour modifier cet enregistrement attendront la fin de la transaction A.

Problèmes possibles : lors de l'exécution d'une requête de plage, des lectures fantômes peuvent se produire.

(3) READ COMMITTED (lecture du commit)

Lors de la lecture des données dans la transaction A, ajoutez un verrou partagé à l'enregistrement, mais lisez La fin est publiée immédiatement. Les autres tentatives de la transaction B pour modifier cet enregistrement attendront la fin du processus de lecture dans A, sans la fin de la transaction A entière. Par conséquent, les résultats de lecture du même enregistrement à différentes étapes de la transaction A peuvent être différents. ,

Problèmes possibles : lecture non répétable.

(4) READ UNCOMMITTED (lecture non validée)

Aucun verrou partagé n'est ajouté. Par conséquent, une autre transaction B peut modifier le même enregistrement pendant que la transaction A lit l'enregistrement, ce qui peut endommager les données lues par A ou les rendre incomplètes ou incorrectes.

De plus, les données modifiées dans la transaction B (non validées) peuvent être lues dans la transaction A. Par exemple, la transaction B a modifié l'enregistrement R, mais celui-ci n'a pas été soumis. A ce moment, lorsque l'enregistrement R est lu dans la transaction A, les données modifiées par B sont lues.                                                                                                                                                       

D : Durée, persistance. Une fois l’exécution de la transaction terminée, l’impact sur les données est persistant, même en cas de panne fatale du système.

Ce qui précède est la re-compréhension des transactions de la base de données MYSQL. Pour plus de contenu connexe, veuillez faire attention au site Web PHP chinois (www.php. .cn) !