Merci pour l'invitation. Metadata Lock (MDL) a été introduit dans le mécanisme de protection des métadonnées de MySQL dans la version 5.5. 5.5 La protection des métadonnées se situe au niveau de la transaction et le MDL n'est publié qu'une fois la transaction terminée. Lorsqu'une session effectue une opération DML dans la base de données principale et n'a pas encore été soumise, une autre session effectue une opération DDL telle que supprimer une table sur le même objet. Puisque le journal binaire de MySQL est enregistré en fonction de l'ordre de soumission des transactions, donc dans. Lors d'une application à partir de la bibliothèque, il y aura une situation dans laquelle la table sera d'abord supprimée puis insérée dans la table, provoquant une erreur dans l'application à partir de la bibliothèque. Par conséquent, MySQL a introduit le verrou des métadonnées après la version 5.5.3. Le verrou des métadonnées ne sera libéré qu'après la fin de la transaction, de sorte que les opérations DDL ne peuvent pas être effectuées avant que la transaction ne soit validée ou annulée. Les causes de l'attente du verrouillage des métadonnées de la table sont généralement les scénarios simples suivants : Scénario 1 : longue transaction en cours d'exécution, bloquant DDL, puis bloquant toutes les opérations ultérieures sur la même table Scénario 2 : La transaction n'est pas soumise, bloquant DDL, puis bloquant toutes les opérations ultérieures sur la même table
Alors comment le résoudre ? Afficher tous les verrous de transaction en attente d'état bloqué
USE INFORMATION_SCHEMA
SELECT *
FROM INNODB_LOCKS
WHERE LOCK_TRX_ID IN (SELECT BLOCKING_TRX_ID FROM INNODB_LOCK_WAITS);
Ou vous pouvez cibler directement une table spécifique
SELECT * FROM INNODB_LOCKS
WHERE LOCK_TABLE = db_name.table_name;
La suppression directe des enregistrements concernés devrait déverrouiller le verrou.
Suggestion : utilisez un pool de connexions au lieu de partager une connexion pour tous les threads, et n'oubliez pas de valider ou d'annuler chaque transaction. Référence recommandée : https://dev.mysql.com/doc/ref... http://www.cnblogs.com/cchust... https://gold .xitu.io/entry/57... http://www.cnblogs.com/digdee...
Tout d'abord, plusieurs threads partagent une seule connexion, ce qui équivaut à la concurrence. De nombreux threads doivent attendre. Le taux d'utilisation d'une connexion par thread n'est pas élevé, il s'agit donc généralement d'un pool de connexions. Il n'y a pas besoin de recyclage et la connexion est toujours maintenue, évitant ainsi les déconnexions fréquentes.
![[Web front-end] Démarrage rapide de Node.js](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
Merci pour l'invitation. Metadata Lock (MDL) a été introduit dans le mécanisme de protection des métadonnées de MySQL dans la version 5.5. 5.5 La protection des métadonnées se situe au niveau de la transaction et le MDL n'est publié qu'une fois la transaction terminée.
Lorsqu'une session effectue une opération DML dans la base de données principale et n'a pas encore été soumise, une autre session effectue une opération DDL telle que supprimer une table sur le même objet. Puisque le journal binaire de MySQL est enregistré en fonction de l'ordre de soumission des transactions, donc dans. Lors d'une application à partir de la bibliothèque, il y aura une situation dans laquelle la table sera d'abord supprimée puis insérée dans la table, provoquant une erreur dans l'application à partir de la bibliothèque. Par conséquent, MySQL a introduit le verrou des métadonnées après la version 5.5.3. Le verrou des métadonnées ne sera libéré qu'après la fin de la transaction, de sorte que les opérations DDL ne peuvent pas être effectuées avant que la transaction ne soit validée ou annulée.
Les causes de l'attente du verrouillage des métadonnées de la table sont généralement les scénarios simples suivants :
Scénario 1 : longue transaction en cours d'exécution, bloquant DDL, puis bloquant toutes les opérations ultérieures sur la même table
Scénario 2 : La transaction n'est pas soumise, bloquant DDL, puis bloquant toutes les opérations ultérieures sur la même table
Alors comment le résoudre ?
Afficher tous les verrous de transaction en attente d'état bloqué
Ou vous pouvez cibler directement une table spécifique
La suppression directe des enregistrements concernés devrait déverrouiller le verrou.
Suggestion : utilisez un pool de connexions au lieu de partager une connexion pour tous les threads, et n'oubliez pas de valider ou d'annuler chaque transaction.
Référence recommandée :
https://dev.mysql.com/doc/ref...
http://www.cnblogs.com/cchust...
https://gold .xitu.io/entry/57...
http://www.cnblogs.com/digdee...
Le tableau provient d'Innodb, mais la soumission automatique n'est pas activée et il n'y a pas de soumission manuelle.
Tout d'abord, plusieurs threads partagent une seule connexion, ce qui équivaut à la concurrence. De nombreux threads doivent attendre.
Le taux d'utilisation d'une connexion par thread n'est pas élevé, il s'agit donc généralement d'un pool de connexions. Il n'y a pas besoin de recyclage et la connexion est toujours maintenue, évitant ainsi les déconnexions fréquentes.
Avec photos, si le sujet a ouvert la transaction