Les caractéristiques acides d'une transaction se réfèrent à l'atomicité, à la cohérence, à l'isolement et à la persistance. L'atomicité garantit que toutes les opérations d'une transaction sont effectuées ou non; La cohérence garantit que la base de données est transférée d'un état cohérent à un autre; L'isolement empêche les interférences mutuelles lorsque plusieurs transactions sont exécutées simultanément; La persistance garantit que les résultats de la transaction sont enregistrés en permanence une fois la transaction engagée. Les transactions garantissent la cohérence des données via le journal de rétablissement, l'annulation du journal et des mécanismes de verrouillage. Le journal de rétablissement est utilisé pour la récupération de crash, l'annulation du journal prend en charge le Rollback et le MVCC, et le mécanisme de verrouillage contr?le un accès simultané pour éviter la lecture sale, la lecture non répréhensible et la lecture fant?me. L'utilisation correcte des transactions nécessite un contr?le raisonnable des limites des transactions et le niveau d'isolement approprié est sélectionné. Par exemple, Read Commited convient à la plupart des scénarios. La lecture reproductible peut éviter la lecture fant?me mais peut augmenter les frais généraux de verrouillage. Les idées fausses courantes incluent la conviction que les transactions peuvent entièrement assurer la sécurité des données, les soumettre et ignorer les problèmes de performance causés par les transactions longues. Dans le développement réel, la granularité des transactions doit être contr?lée, rapidement dans et hors, et la fiabilité doit être améliorée en combinaison avec la réplication ma?tre-esclave et d'autres mécanismes.

Une transaction MySQL fait référence à un ensemble d'instructions SQL qui sont exécutées dans son ensemble. Il succède à tout ou échoue tous les reculs et ne reste pas dans un état intermédiaire. Ce mécanisme est un moyen clé pour assurer la cohérence des données.

Quelle est la caractéristique acide d'une transaction?

Les transactions doivent répondre à quatre caractéristiques: l'atomicité, la cohérence, l'isolement et la persistance , qui est communément appelée acide.

• Atomicité : toutes les opérations d'une transaction sont effectuées ou non.
• Cohérence : la transaction doit modifier la base de données d'un état cohérent à un autre.
• Isolement : Lorsque plusieurs transactions sont exécutées simultanément, l'exécution d'une transaction ne doit pas affecter d'autres transactions.
• Persistance : une fois une transaction engagée, le résultat est permanent et ne sera pas perdu même si le système se bloque.

Ces quatre fonctionnalités fonctionnent ensemble pour s'assurer que les données restent correctes et cohérentes dans l'accès ou les exceptions simultanées.

Comment assurer la cohérence des données dans les transactions?

La transaction elle-même ne peut pas directement ?garantie? la cohérence. Il obtient indirectement la garantie de cohérence par le biais du mécanisme de journalisation sous-jacent (tel que le journal de rétablissement, le journal d'annulation) et le mécanisme de verrouillage .

• Recotor : enregistre les modifications physiques de la transaction sur la page de données et est utilisée pour rejouer la transaction engagée lors de la récupération du crash.
• Annuler le journal : enregistre l'état avant la modification des données, utilisé pour le retrait des transactions et le MVCC (contr?le de concurrence multi-version).
• Mécanisme de verrouillage : comprend des verrous au niveau des lignes, des verrous au niveau de la table, etc., qui sont utilisés pour contr?ler l'accès des transactions simultanées à la même ressource et empêcher la lecture sale, la lecture non répattable et la lecture fantastique.

Par exemple, lorsque deux transactions modifient le même enregistrement en même temps, s'il n'y a pas de mécanisme de verrouillage, les données peuvent être écrasées ou incohérentes. L'utilisation des verrous de ligne moteur InNODB combinés avec le niveau d'isolement des transactions peut effectivement éviter ce type de problème.

Comment utiliser correctement les transactions?

La clé de l'utilisation des transactions est de contr?ler raisonnablement les limites des transactions et de sélectionner le niveau d'isolement des transactions approprié.

Une pratique courante consiste à ouvrir explicitement les transactions dans votre code:

 Démarrer la transaction;
- Effectuer plusieurs comptes de mise à jour des opérations SQL set Balance = Balance - 100 où user_id = 1;
Mettre à jour les ordres set status = 'payé' où ordonnance_id = 1001;
COMMETTRE;

Si une erreur se produit au milieu, vous pouvez exécuter ROLLBACK en arrière pour faire reculer toute la transaction.

Remarque également:

• Ne mettez pas trop d'opérations non pertinentes dans une seule transaction, sinon cela fera facilement attendre les verrous ou même les impasses.
• Choisissez le niveau d'isolement approprié en fonction des besoins de l'entreprise. Par exemple, Lire engagée (Lire engagée) convient à la plupart des scénarios, et la lecture reproductible (lecture reproductible) peut éviter la lecture des fant?mes, mais peut apporter des frais généraux de verrouillage plus élevés.

Malentendus et précautions courantes

Beaucoup de gens pensent que tant que les transactions sont utilisées, les données seront s?res, mais en fait, ce n'est pas le cas.

• S'il n'y a pas de verrouillage dans la transaction, des conflits d'écriture simultanés peuvent encore se produire.
• Après avoir soumis la transaction, le disque n'est pas abandonné immédiatement, mais s'appuie sur le pool de tampons et le mécanisme de journal pour rincer le disque de manière asynchrone. Dans les cas extrêmes, les données peuvent encore être perdues (comme la panne de courant). à l'heure actuelle, il est nécessaire de combiner la veille chaude à double machine, la réplication ma?tre-esclave et d'autres mécanismes pour améliorer la disponibilité et la fiabilité.
• Les transactions longues sont susceptibles de provoquer des problèmes de performance, tels que l'expansion du journal d'annulation, la concurrence intensifiée de verrouillage et les versions MVCC excessives.

Par conséquent, dans le développement réel, nous devons prêter attention au contr?le de la granularité de la transaction, à éviter de traiter une grande quantité de logique dans une transaction et d'essayer d'atteindre "rapidement dans et sortir".

Fondamentalement, c'est tout. Les affaires ne sont pas une panacée, et elle n'est efficace que si vous l'utilisez bien.

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!