Cet article présente principalement des informations pertinentes sur les problèmes rencontrés par les transactions imbriquées MySQL. Les amis qui en ont besoin peuvent s'y référer
MySQL prend en charge les transactions imbriquées, mais peu de gens le faisaient il y a quelque temps. J'ai vu des étrangers discuter de la nécessité des transactions imbriquées MySQL à l'étranger. Cela m'amuse à mort. Pourquoi y a-t-il une nécessité de scène pour cette utilisation de fantômes imbriqués ? J'ai parlé à mes anciens collègues DBA et appris que les transactions imbriquées MySQL ne doivent être utilisées dans aucun scénario.
Alors, quels problèmes rencontrerez-vous lors de l'utilisation des transactions imbriquées MySQL ?
mysql> select * from ceshi; +------+ | n | +------+ | 1 | +------+ 1 row in set (0.00 sec) mysql> start transaction ; Query OK, 0 rows affected (0.00 sec) mysql> insert into ceshi values(2); Query OK, 1 row affected (0.00 sec) mysql> start transaction ; Query OK, 0 rows affected (0.00 sec) mysql> insert into ceshi values(3); Query OK, 1 row affected (0.00 sec) mysql> commit; Query OK, 0 rows affected (0.00 sec) mysql> rollback; Query OK, 0 rows affected (0.00 sec)
Bien que j'aie annulé à la fin, mais l'affichage des données est 1 2 3 . À l'origine, tout le monde pensait que même si ma transaction était dans un état imbriqué, j'avais l'impression qu'elle avait finalement été annulée. En fait, ce que nous voulons voir, c'est que la sous-transaction est exécutée. avec succès, et l'échec de la transaction externe sera renvoyé. Sortez d'ici. Mais ce n'est pas le cas. Le résultat final est 1 2 3.
+-----+ | n | +-----+ | 1 | | 2 | | 3 | +-----+
Lorsque l'interpréteur SQL rencontre une transaction de démarrage, la validation sera déclenché. … !!! Si vous faites un rollback à ce moment-là, cela ne servira certainement à rien... Parce qu'il a déjà été soumis, que pouvez-vous restaurer...
Comme mentionné précédemment, en termes de l'architecture, il y a généralement très peu de personnes qui utilisent des transactions imbriquées, mais parfois elles sont imbriquées accidentellement. Prenons l'exemple du projet python. Tout d'abord, nous utilisons des décorateurs pour implémenter le packaging des transactions. Ensuite, les fonctions de traitement des données def a() et def b() sont enveloppées par des transactions. .Opération unique. Si une logique appelle à nouveau b, que se passera-t-il ? Oui, les transactions sont imbriquées... Je pense que c'est un problème que la plupart des développeurs commerciaux rencontreront. begin_1 sql_1 begin_2 sql_2 sql_3 commit_1 rollback_1 .
Lorsque nous exécutons l'instruction suivante, la transaction sera forcée de s'engager. Bien sûr, la prémisse ici est autocommit = True.
@decorator def with_transaction(f, *args, **kwargs): db = connection.get_db_by_table("*") try: db.begin() ret = f(*args, **kwargs) db.commit() except: db.rollback() raise return ret @with_transaction def hide(self): '''订单不在app端显示''' if self.status not in OrderStatus.allow_deletion_statuses(): raise OrderStatusChangeNotAllowed(self.status, OrderStatus.deleted) ... @with_transaction def change_receipt_info(self, address, name, phone): region = Region.get_by_address(address) ...
Ce qui précède est une explication détaillée des exemples de code des problèmes rencontrés par les transactions imbriquées MySQL. Pour plus de contenu connexe, veuillez faire attention au PHP. Site chinois (www .php.cn) !
ALTER FUNCTION ALTER PROCEDURE ALTER TABLE BEGIN CREATE DATABASE CREATE FUNCTION CREATE INDEX CREATE PROCEDURE CREATE TABLE DROP DATABASE DROP FUNCTION DROP INDEX DROP PROCEDURE DROP TABLE UNLOCK TABLES LOAD MASTER DATA LOCK TABLES RENAME TABLE TRUNCATE TABLE SET AUTOCOMMIT=1 START TRANSACTION