mysql avancé (4) sélection mysql

sélectionnez * pour la mise à jour

dans mysql Remarque :

FOR UPDATE n'est applicable qu'à InnoDB et doit être dans le bloc de transaction (BEGIN/COMMIT) pour prendre effet.

Fonction

Verrouille l'objet sélectionné par cette instruction. Cela évite les incohérences des données causées par la modification de ces objets ailleurs après la sélection. Pour garantir que les enregistrements ne soient pas mis à jour par d'autres utilisateurs lors de l'exécution des statistiques (requête),

peut être verrouillé à l'aide de la clause For update. De cette manière, les autres utilisateurs ne peuvent pas mettre à jour, supprimer ou verrouiller ces enregistrements avant que le verrouillage ne soit libéré.

Sélectionnez daptno from dept Where deptno=25 Pour la mise à jour
Si vous utilisez FOR UPDATE pour verrouiller la table, vous devez utiliser commit pour libérer les enregistrements verrouillés.

Les verrous sont divisés en deux catégories : la clause de portée de verrouillage et la clause de comportement de verrouillage Clause de portée de verrouillage : après la sélection... pour la mise à jour, vous pouvez utiliser la clause of pour sélectionner l'option de sélection Effectuer le verrouillage opérations sur des tables de données spécifiques. Par défaut, ne pas utiliser la clause of signifie verrouiller toutes les tables de données dans la clause de comportement de verrouillage : lorsque nous effectuons l'opération for update, elle est très différente de la sélection ordinaire. Généralement, la sélection n'a pas besoin de déterminer si les données sont verrouillées et lit tout au plus la version précédente en fonction de la fonctionnalité de lecture cohérente multi-versions.
La règle pour l'instruction UPDATE verrouillera les tuples dans les résultats de la requête. Ces tuples ne seront pas exploités par UPDATE, delete et pour UPDATE d'autres transactions jusqu'à ce que cette transaction soit validée.

Scénarios d'application

Alors, quand devez-vous utiliser pour la mise à jour ? Lorsque les données au niveau de l'entreprise doivent être exclusives, vous pouvez envisager de les utiliser pour la mise à jour. Dans des scénarios tels que la réservation de billets de train, les billets restants sont affichés à l'écran. Lors de l'émission réelle des billets, vous devez reconfirmer que les données n'ont pas été modifiées par d'autres clients. Par conséquent, au cours de ce processus de confirmation, vous pouvez utiliser la mise à jour. Il s'agit d'un problème de solution unifiée qui nécessite une préparation à l'avance.

Étant donné qu'InnoDB est par défaut sur le verrouillage au niveau des lignes, MySQL exécutera le verrouillage des lignes uniquement si la clé primaire est "explicitement" spécifiée (seule la clé sélectionnée sera verrouillée ) Exemple de données), sinon MySQL exécutera Table Lock (verrouillera l'intégralité du formulaire de données).

Exemple 1

Permettez-moi de vous donner quelques exemples :

select * from t for update 会等待行锁释放之后，返回查询结果。
select * from t for update nowait 不等待行锁释放，提示锁冲突，不返回结果
select * from t for update wait 5 等待5秒，若行锁仍未释放，则提示锁冲突，不返回结果
select * from t for update skip locked 查询返回查询结果，但忽略有行锁的记录

La syntaxe de l'instruction SELECT...FOR UPDATE est la suivante :
　

　SELECT ... FOR UPDATE [OF column_list][WAIT n|NOWAIT][SKIP LOCKED];

Où :
　La clause OF est utilisée pour spécifier la colonne à mettre à jour, c'est-à-dire pour verrouiller une colonne spécifique sur la ligne.
La clause WAIT spécifie le nombre de secondes à attendre avant que les autres utilisateurs libèrent le verrou pour éviter une attente indéfinie.

Les avantages de la clause "USE FOR UPDATE WAIT" sont les suivants :
1. Empêche d'attendre indéfiniment les lignes verrouillées ; 2. Permet à l'application d'avoir plus de contrôle sur le temps d'attente du verrouillage.
　3 Très utile pour les applications interactives, car ces utilisateurs ne peuvent pas attendre indéfiniment
　4 Si le saut verrouillé est utilisé, les lignes verrouillées peuvent être ignorées et le rapport d'exception 'ressource occupée' provoqué par l'attente n ne sera pas signalé

Exemple 2

Supposons qu'il existe un formulaire products, qui comporte deux champs, id et name, et id est la clé primaire.

Exemple 1 : (Spécifiez explicitement la clé primaire, et il y a ces données, verrouillage de ligne)

SELECT * FROM products WHERE id='3' FOR UPDATE;
SELECT * FROM products WHERE id='3' and type=1 FOR UPDATE;

Exemple 2 : (Spécifiez explicitement la clé primaire, s'il n'y a pas de telles données , il n'y a pas de verrou)

SELECT * FROM products WHERE id='-1' FOR UPDATE;

Exemple 2 : (Pas de clé primaire, verrouillage de table)

SELECT * FROM products WHERE name='Mouse' FOR UPDATE;

Exemple 3 : (La clé primaire n'est pas claire, verrouillage de la table)

SELECT * FROM products WHERE id<>&#39;3&#39; FOR UPDATE;

Exemple 4 : (La clé primaire n'est pas claire, verrouillage de la table)

SELECT * FROM products WHERE id LIKE '3' FOR UPDATE;

Remarque 1 : FOR UPDATE n'est applicable qu'à InnoDB et doit être dans le bloc de transaction (BEGIN/COMMIT) pour prendre effet.

Remarque 2 : Pour tester la situation de verrouillage, vous pouvez utiliser le mode commande de MySQL pour ouvrir deux fenêtres à des fins de test.

C'est effectivement le cas lors du test dans MySql 5.0.

De plus : MyAsim ne prend en charge que les verrous au niveau de la table, tandis qu'InnerDB prend en charge les verrous au niveau des lignes.

Les données avec un verrouillage ajouté (verrouillage au niveau de la ligne/verrouillage au niveau de la table) ne peuvent pas être verrouillées par d'autres transactions, ni être modifiées (modifiées, supprimées) par d'autres transactions lorsqu'il s'agit d'un niveau de table. verrouiller, que l'enregistrement soit interrogé ou non, La table sera verrouillée.

De plus, si A et B interrogent tous deux l'ID de table mais ne peuvent pas interroger l'enregistrement, A et B n'effectueront pas de verrouillage de ligne sur la requête, mais A et B acquerront tous deux des verrous exclusifs à ce moment-là. A Si vous insérez un autre enregistrement, il sera en attente car B a déjà le verrou. À ce moment-là, B insérera à nouveau les mêmes données et lancera un blocage trouvé en essayant d'obtenir le verrou ; essayez de redémarrer la transaction, puis relâchez le verrou. À ce moment-là, A obtiendra Le verrou a été inséré avec succès.

Supplément de connaissances

Le verrouillage est un concept très important dans la base de données. Il est principalement utilisé pour garantir l'intégrité et la cohérence de la base de données dans un environnement multi-utilisateurs. Nous savons que si plusieurs utilisateurs peuvent manipuler des données dans la même base de données en même temps, des incohérences se produiront. Autrement dit, s'il n'y a pas de verrous et que plusieurs utilisateurs accèdent à une base de données en même temps, des problèmes peuvent survenir lorsque leurs transactions utilisent les mêmes données en même temps. Ces problèmes incluent : les mises à jour perdues, les lectures sales, les lectures non répétables et les lectures fantômes :

1. Le problème de perte de mise à jour se produit lorsque deux transactions ou plus sélectionnent la même ligne, puis mettent à jour cette ligne en fonction de la valeur initialement sélectionnée. Chaque transaction ignore l'existence d'autres transactions. La dernière mise à jour écrasera les mises à jour effectuées par d'autres transactions, ce qui entraînera une perte de données. Par exemple, deux éditeurs produisent des copies électroniques du même document. Chaque éditeur apporte des modifications à sa copie de manière indépendante, puis enregistre la copie modifiée, écrasant ainsi le document original. Le dernier éditeur à enregistrer une copie de ses modifications écrase les modifications apportées par le premier éditeur. Ce problème peut être évité si le deuxième éditeur ne peut pas apporter de modifications tant que le premier n'a pas terminé.

2. Une lecture sale signifie que lorsqu'une transaction accède aux données et a modifié les données, mais que la modification n'a pas encore été soumise à la base de données, une autre transaction accède également aux données, puis est utilisée. ces données. Étant donné que ces données n'ont pas encore été validées, les données lues par une autre transaction sont des données sales et les opérations basées sur ces données sales peuvent être incorrectes. Par exemple, un éditeur apporte des modifications à un document électronique. Pendant le processus de modification, un autre éditeur fait une copie du document (la copie contient toutes les modifications apportées jusqu'à présent) et la distribue aux utilisateurs prévus. Après cela, le premier éditeur a décidé que les modifications apportées jusqu'à présent étaient erronées, a supprimé les modifications et a enregistré le document. Les documents distribués aux utilisateurs contiennent des modifications qui n'existent plus et seront réputés n'avoir jamais existé. Ce problème peut être évité si personne ne peut lire le document modifié jusqu'à ce que le premier éditeur finalise les modifications.

3． La lecture non répétable fait référence à la lecture des mêmes données plusieurs fois au cours d'une transaction. Avant la fin de cette transaction, une autre transaction accède également aux mêmes données. Ensuite, entre les deux lectures de données de la première transaction, du fait de la modification de la deuxième transaction, les données lues deux fois par la première transaction peuvent être différentes. De cette façon, les données lues deux fois au sein d’une transaction sont différentes, on parle donc de lecture non répétable. Par exemple, un éditeur lit deux fois le même document, mais entre les lectures, l'auteur réécrit le document. Lorsque l'éditeur lit le document une seconde fois, le document a changé. Les lectures brutes ne sont pas reproductibles. Ce problème peut être évité si les éditeurs ne peuvent lire le document qu'une fois que l'auteur a fini de l'écrire.

4． La lecture fantôme fait référence à un phénomène qui se produit lorsque les transactions ne sont pas exécutées indépendamment. Par exemple, la première transaction modifie les données d'une table, et cette modification concerne toutes les lignes de données de la table. Parallèlement, la deuxième transaction modifie également les données de cette table. Cette modification insère une ligne de nouvelles données dans la table. Puis, à l’avenir, l’utilisateur qui effectue la première transaction constatera qu’il reste des lignes de données non modifiées dans la table, comme si une hallucination s’était produite. Par exemple, un éditeur modifie un document soumis par un auteur, mais lorsque la production fusionne ses modifications dans la copie principale du document, on découvre que l'auteur a ajouté du nouveau matériel non édité au document. Ce problème peut être évité si personne ne peut ajouter de nouveaux éléments au document tant que les éditeurs et le service de production n'ont pas fini de travailler sur le document original.

Par conséquent, la façon de gérer l'accès simultané de plusieurs utilisateurs est de verrouiller. Les verrous sont un moyen majeur d'empêcher d'autres transactions d'accéder aux contrôles de ressources spécifiés et d'obtenir un contrôle de concurrence. Lorsqu'un utilisateur verrouille un objet dans la base de données, les autres utilisateurs ne peuvent plus accéder à l'objet. L'impact du verrouillage sur les accès concurrents se reflète dans la granularité du verrouillage. Afin de contrôler les ressources verrouillées, vous devez d'abord comprendre la gestion de l'espace du système.

Ce qui précède est le contenu de mysql select dans Advanced mysql (4). Pour plus de contenu connexe, veuillez faire attention au site Web PHP chinois (www.php.cn) !