Causes et solutions des blocages de bases de données-tutoriel mysql-php.cn

Causes et solutions aux blocages de base de données : 1. Un bug se produit dans le programme et la logique du programme doit être ajustée ; 2. Les boutons sur la page ne prennent pas effet immédiatement et les verrous optimistes et des verrous pessimistes doivent être utilisés pour le contrôle ; 3. , exécuter plusieurs instructions de mise à jour qui ne remplissent pas les conditions. Les instructions doivent être analysées et les index correspondants établis pour l'optimisation.

Causes et solutions des blocages de bases de données

Causes et solutions aux blocages de base de données :

Il existe deux types de verrous de base dans la base de données : 排它锁 (Verrous exclusifs, c'est-à-dire le verrou X) et 共享锁 (Partager les verrous, c'est-à-dire le verrou S). Lorsqu'un objet de données est verrouillé exclusivement, les autres transactions ne peuvent pas le lire ou le modifier. Les objets de données avec des verrous partagés peuvent être lus par d'autres transactions, mais ne peuvent pas être modifiés. La base de données utilise ces deux types de verrous de base pour contrôler la simultanéité des transactions de la base de données.

Tutoriels graphiques associés : Tutoriel graphique de base de données mysql

Le premier cas de blocage

A l'utilisateur A accède à la table A (verrouille la table A), puis accède à la table B ; un autre utilisateur B accède à la table B (verrouille la table B), puis tente d'accéder à la table A à ce moment-là, l'utilisateur A en raison de l'utilisateur B a verrouillé la table ; B. Il doit attendre que l'utilisateur B libère la table B avant de pouvoir continuer. De même, l'utilisateur B doit attendre que l'utilisateur A libère la table A avant de pouvoir continuer.

Solution :

Ce type de blocage est relativement courant et est causé par des bugs dans le programme. Il n'y a pas d'autre solution que d'ajuster la logique du programme. Analysez attentivement la logique du programme. Lorsque vous utilisez plusieurs tables dans la base de données, essayez de les traiter dans le même ordre et essayez d'éviter de verrouiller deux ressources en même temps. Par exemple, lorsque vous utilisez deux tables A et B, traitez toujours. les dans l'ordre de A d'abord, puis de B. , Lorsque deux ressources doivent être verrouillées en même temps, il faut s'assurer que les ressources doivent être verrouillées dans le même ordre à tout moment.

Le deuxième cas de blocage

L'utilisateur A interroge un enregistrement puis modifie l'enregistrement ; puis l'utilisateur B modifie l'enregistrement, puis l'utilisateur A La nature du verrouillage ; la transaction tente d'être augmentée du verrou partagé de la requête à un verrou exclusif, et le verrou exclusif de l'utilisateur B doit attendre que A libère le verrou partagé car A a un verrou partagé, et A ne peut pas être augmenté en raison de B verrou exclusif. Il est impossible pour le verrou exclusif de libérer le verrou partagé, un blocage se produit donc. Ce type de blocage est relativement caché, mais il se produit souvent dans les projets de plus grande envergure. Par exemple, dans un projet, après avoir cliqué sur un bouton de la page, le bouton ne devient pas immédiatement invalide, ce qui oblige l'utilisateur à cliquer plusieurs fois rapidement sur le même bouton. De cette manière, le même morceau de code effectue plusieurs opérations sur le même. enregistrement dans la base de données, et ce type d’échec peut facilement se produire.

Solution :

1 Pour les contrôles tels que les boutons, rendez-les invalides immédiatement après avoir cliqué pour empêcher les utilisateurs de cliquer à plusieurs reprises et éviter d'opérer sur le même enregistrement en même temps. en même temps.

2. Utilisez le verrouillage optimiste pour le contrôle. Le verrouillage optimiste est principalement mis en œuvre sur la base du mécanisme d'enregistrement de la version des données (Version). Il s'agit d'ajouter un identifiant de version aux données. Dans les solutions de version basées sur des tables de base de données, cela est généralement réalisé en ajoutant un champ « version » à la table de base de données. Lorsque les données sont lues, ce numéro de version est également lu, et lors d'une mise à jour ultérieure, ce numéro de version est incrémenté de un. À ce stade, les données de version des données soumises sont comparées aux informations de version actuelle de l'enregistrement correspondant dans la table de base de données. Si le numéro de version des données soumises est supérieur au numéro de version actuel de la table de base de données, il sera. mises à jour, sinon elles seront considérées comme des données expirées. Le mécanisme de verrouillage optimiste évite la surcharge de verrouillage de la base de données dans les transactions longues (ni l'utilisateur A ni l'utilisateur B ne verrouillent les données de la base de données pendant l'opération), ce qui améliore considérablement les performances globales du système dans des conditions de concurrence importante. Hibernate dispose d'une implémentation de verrouillage optimiste intégrée à son moteur d'accès aux données. Il convient de noter que puisque le mécanisme de verrouillage optimiste est implémenté dans notre système, les opérations de mise à jour des utilisateurs à partir de systèmes externes ne sont pas contrôlées par notre système, de sorte que des données sales peuvent être mises à jour dans la base de données.

3. Utilisez le verrouillage pessimiste pour le contrôle. Dans la plupart des cas, le verrouillage pessimiste s'appuie sur le mécanisme de verrouillage de la base de données, tel que l'instruction Select... for update d'Oracle, pour garantir l'exclusivité maximale de l'opération. Mais il s’ensuit une surcharge importante en termes de performances de la base de données, en particulier pour les transactions longues, ce qui est souvent insupportable. Par exemple, dans un système financier, lorsqu'un opérateur lit les données utilisateur et apporte des modifications en fonction des données utilisateur lues (telles que la modification du solde du compte utilisateur), si un mécanisme de verrouillage pessimiste est utilisé, cela signifie que l'ensemble du processus opérationnel (le processus complet depuis l'opérateur lisant les données, commençant la modification jusqu'à la soumission du résultat de la modification, et même incluant le moment où l'opérateur est allé préparer le café au milieu), les enregistrements de la base de données sont toujours verrouillés si vous faites face à des centaines. ou des milliers de concurrences, une telle situation entraînerait des conséquences catastrophiques. Par conséquent, vous devez y réfléchir attentivement lorsque vous utilisez le verrouillage pessimiste à des fins de contrôle.

Le troisième cas d'impasse

Si une instruction de mise à jour qui ne remplit pas les conditions est exécutée dans une transaction, une analyse complète de la table sera effectuée et le verrou au niveau de la ligne sera mis à niveau vers un verrou au niveau de la table. Après l'exécution de plusieurs transactions de ce type, un blocage est possible. et le blocage se produira facilement. Une situation similaire se produit lorsque la quantité de données dans la table est très importante et que le nombre d'index créés est trop petit ou inapproprié, ce qui entraîne de fréquentes analyses complètes de la table. En fin de compte, le système d'application deviendra de plus en plus lent, et finira par se bloquer ou. une impasse se produira.

Solution :

N'utilisez pas de requêtes trop complexes qui relient plusieurs tables dans des instructions SQL ; utilisez le « plan d'exécution » pour analyser l'instruction SQL pour analyser des tables complètes. les instructions SQL et créer les index correspondants pour l'optimisation.