Dans l'instruction d'écriture de MySql, lorsque la valeur attribuée à la colonne du tableau ne correspond pas au type de table, l'optimiseur sous-jacent de MySql prendra effet et effectuera une conversion de type forcée. À ce moment, l'opération peut être normale, mais le verrou de ligne sera mis à niveau vers le verrou de table. L'exemple est le suivant
En prenant comme exemple la table des étudiants, le type de champ de la table :
Le contenu de la table est le suivant :
Ouvrez deux fenêtres de session et changez le mode de soumission automatique de MySql dans les deux fenêtres de session en soumission manuelle
>set autocommit=false;
Exécutez l'instruction de mise à jour dans la fenêtre de session 1, mais ne validez pas la transaction . La colonne age est spécifiée comme type int lors de la création de la table. La chaîne « 100 » est utilisée pour l'affectation dans l'instruction de mise à jour. L'optimiseur MySql convertira automatiquement la chaîne « 100 » en un entier 100, puis effectuera la récupération SQL. .
>update student set class=3 where age='100'
Effectuez ensuite des opérations de mise à jour sur d'autres données non pertinentes dans la fenêtre de session 2
>update student set age=28 where name='lzj';
Dans des circonstances normales, les données de ligne exploitées par les deux instructions SQL sont différentes et elles interagiront les uns avec les autres pendant l'exécution. Cela n'affecte pas, mais l'opération de mise à jour réelle dans la session 1 bloque l'opération de mise à jour dans la session 2
L'opération de mise à jour est effectuée dans la session 1, mais aucune soumission de transaction n'est effectuée. Le niveau de la transaction est Lecture Commise, donc dans la session Les résultats mis à jour de la session 1 ne sont pas encore visibles dans 2. Cependant, lors de l'exécution d'opérations de mise à jour des données sur d'autres lignes de la session 2, un blocage s'est produit. On peut voir que l'affectation de l'instruction SQL dans la session 1 a été forcée, provoquant la mise à niveau du verrou de ligne de la session 1 vers un verrou de table, verrouillant la totalité de la table étudiant, et donc le SQL de la session 2 a été bloqué. Ensuite, effectuez une validation de transaction sur l'opération de mise à jour dans la session 1, puis l'opération de mise à jour dans la session 2 continuera à être exécutée
Exécutez l'opération de mise à jour dans la session 1commit
Après avoir soumis manuellement la transaction, session 1 est libéré Libérez le verrou de la table de l'étudiant et l'opération de mise à jour de la session 2 peut continuer à être exécutée.
Enfin, commit
la soumission de transaction est également exécutée pour la mise à jour de la session 2. Les deux instructions SQL sont mises à jour. Le contenu de la table étudiant est le suivant :
Depuis le. Dans le cas ci-dessus, l'instruction SQL. Lorsque l'affectation ne correspond pas au type de colonne de la table, l'optimiseur de MySql force la conversion vers un type correspondant, provoquant la mise à niveau du verrou de ligne vers un verrou de table. Par conséquent, vous devez faire attention à la correspondance de type pendant le développement pour éviter que les verrous de ligne ne soient mis à niveau vers des verrous de table, ce qui affecterait les performances de concurrence.
Recommandations associées :
Utilisation du verrouillage MySQL, verrouillage au niveau de la table
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!