Résumé des caractéristiques ACID et des problèmes de concurrence des transactions MySQL

Cet article vous apporte des connaissances pertinentes sur mysql. Il présente principalement les caractéristiques ACID des transactions MySQL et les solutions aux problèmes de concurrence. L'article fournit une introduction détaillée sur le sujet, qui a une certaine valeur de référence. J'espère que cela sera utile à tout le monde.

Apprentissage recommandé : Tutoriel vidéo mysql

1. Le concept de transaction

Une transaction est une unité indivisible composée d'une ou plusieurs instructions SQL qui opèrent sur la base de données uniquement lorsque la transaction est l'intégralité de la transaction. ne sera soumis à la base de données qu'une fois que toutes les opérations auront été exécutées normalement. Si une partie de la transaction échoue, la transaction sera restaurée à son état d'origine. Par conséquent, soit la transaction sera exécutée avec succès, soit elle échouera.

Vous devez donc vous rappeler quelques concepts de base des transactions, comme suit :

Une transaction est l'exécution d'un ensemble d'instructions SQL. Soit toutes réussissent, soit toutes échouent. Il ne peut y avoir de succès ou d'échec partiel. l’atomicité de l’exécution des transactions fonctionne. Ce n'est que lorsque toutes les instructions SQL de la transaction sont exécutées avec succès que la transaction peut être validée et les résultats écrits sur le disque. Lors de l'exécution de la transaction, si des erreurs SQL se produisent, la transaction doit être restaurée à son état d'origine.

Par exemple, l'activité de transfert nécessite que plusieurs instructions SQL soient complétées ensemble. Ce n'est que lorsque ces instructions SQL sont exécutées avec succès que l'entreprise peut être considérée comme réussie.

Le traitement des transactions a trois états :

begin : toutes les instructions SQL à exécuter pour démarrer une transaction réussissent, puis commitsoumet une transaction si l'une des instructions SQL est due. une panne de courant ou un serveur. Si une erreur se produit, entraînant une exception d'exécution SQL, la transaction ne sera pas soumise, la transaction sera annulée (rollback) et les données seront restaurées à l'état où elles étaient avant le début de la transaction

Ceci est garanti par le moteur de stockage (garanti par redo log et undo log)

Le moteur de stockage MyISAM ne prend pas en charge les transactions, tandis que le moteur de stockage InnoDB prend en charge les transactions et les verrous de ligne.

Utilisez show moteursG pour vérifier quels moteurs de stockage sont pris en charge par la base de données actuelle.

show enginesG查看当前数据库支持哪些存储引擎。

select @@autocommit;

select @@autocommit;Afficher les paramètres de l'état de validation de la transaction<img alt="" src="https://img.php.cn/upload/article/000/000/067/a436295269b7a6438302b813398a2dde-3.png">

Le moteur de base de données peut être temporairement modifié via des commandes ou modifié de manière permanente via des fichiers de configuration.

Si notre activité implique des transactions, nous contrôlons généralement cette variable dans le code. De manière générale, nos transactions sont constituées de plusieurs SQL et doivent répondre à l'atomicité de la transaction, nous la définissons donc sur soumission manuelle. Si l'entreprise réussit, la transaction sera soumise ; en cas d'échec au milieu de l'entreprise, une transaction sera annulée.

2. Caractéristiques ACIDES

Chaque transaction doit répondre aux 4 caractéristiques suivantes : 🎜🎜

L'atomicité(Atomique) d'une transaction : Une transaction est un tout indivisible. La transaction doit avoir des caractéristiques atomiques, et lorsque la transaction est modifiée, soit tout sera exécuté, soit aucun ne sera exécuté, c'est-à-dire partiel. la réalisation de la transaction n'est pas autorisée. Transaction Cohérence(Cohérence) : Avant et après l'exécution d'une transaction, les données de la base de données doivent maintenir un état cohérent. L'état de cohérence de la base de données doit relever de la responsabilité de l'utilisateur et mis en œuvre par le mécanisme de contrôle de concurrence. Prenons l'exemple des achats en ligne. Ce n'est qu'en laissant les marchandises quitter l'entrepôt et en entrant dans le panier du client qu'une transaction complète peut être effectuée. (La cohérence ne se reflète pas seulement dans les transactions, mais inclut également l'introduction de MySQL dans la couche de stockage. Afin d'améliorer l'efficacité de l'accès aux données du hotspot, une couche de cache Redis ou un cache Memery est généralement ajoutée pour mettre en cache les données du hotspot, ce qui implique les données de la couche cache et de la couche base de données (problème de cohérence) Isolation des transactions (Isolution) : lorsque deux ou plusieurs transactions sont exécutées simultanément, afin de garantir la sécurité des données, les opérations au sein d'une transaction sont isolées des opérations des autres. transactions et ne sont pas affectées par d'autres transactions. La transaction exécutée voit que empêche les transactions exécutées simultanément de s'affecter mutuellement . Niveau d'isolement : sécurité des données et concurrence des transactions. Plus l'isolement est strict, plus la sécurité est élevée et plus la concurrence est faible (c'est-à-dire le contrôle de la concurrence, garantissant la sécurité des données) Durabilité de la transaction : une fois la transaction terminée (la validation de la transaction est réussie), le SGBD garantit qu'elle le fera. conserver les données dans la base de données La modification est permanente Même si la base de données échoue en raison d'une panne, les données doivent pouvoir être restaurées. La chose la plus importante à propos de MySQL est le journal, pas les données !

La fonctionnalité ACD des transactions est garantie par les mécanismes de journalisation et d'annulation de MySQL ; l'isolement est garanti par le mécanisme de verrouillage des transactions mysql.

3. Problèmes de concurrence des transactions

Le traitement des transactions n'est pas isolé et les problèmes suivants se produisent généralement lors de l'exécution simultanée de transactions :

Lecture sale : une transaction lit les données non validées d'une autre transaction. Par exemple, lorsque la transaction A et la transaction B sont exécutées simultanément, après la mise à jour de la transaction A, la transaction B interroge et lit les données non validées de A. À ce moment, la transaction A est annulée et les données lues par la transaction B sont des données sales non valides. (

La transaction B lit les données non validées de la transaction A

) Lecture non répétable (Lecture non répétable) : L'opération d'une transaction amène une autre transaction à lire des données différentes deux fois avant et après. Par exemple, lorsque la transaction A et la transaction B sont exécutées simultanément, après que la transaction B a interrogé et lu les données, la transaction A met à jour les données interrogées par la transaction B. À ce moment, la transaction B lit à nouveau les données et constate que les données lues deux fois auparavant et après ne sont pas les mêmes. (

Transaction B lit les données soumises de la transaction A

) Phantom Read(Phantom Read) Lecture fantôme : l'opération d'une transaction fait que le volume de données des résultats des deux requêtes avant et après une autre transaction est différent. Par exemple, lorsque la transaction A et la transaction B sont exécutées simultanément, après que la transaction B ait interrogé et lu des données, la transaction A ajoute ou supprime un enregistrement qui répond aux conditions de requête de la transaction B. À ce moment, la transaction B interroge à nouveau et constate que le précédent la requête n'a pas enregistré d'enregistrements existants ou certains enregistrements de la requête précédente sont manquants. (La transaction B a lu les données nouvellement ajoutées de la transaction A ou n'a pas pu lire les données supprimées par la transaction A)Les lectures sales doivent être éliminées car la transaction n'est pas validée. Dans certains scénarios, les lectures non répétables et les lectures fantômes sont autorisées (la transaction a été validée), mais ne doivent pas être éliminées (en définissant différents niveaux d'isolement), ce qui est déterminé par les exigences du scénario d'application. 4. Commandes liées aux transactions

Vérifiez si MySQL soumet automatiquement les transactions

select @@autocommit;0 signifie soumission manuelle des transactions, 1 signifie soumission automatique des transactions, définissez la méthode de soumission des transactions sur soumission manuelle (affecte uniquement la session en cours) :

Apprentissage recommandé : tutoriel vidéo mysql

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!