Probleme und Verarbeitung der MySQL Innodb-Transaktionsprogrammierung

1. Probleme beim Senden in Schleifen

Viele Entwickler senden Transaktionen gerne in Schleifen. Hier ist ein Beispiel für eine gespeicherte Prozedur, die sie häufig schreiben, wie unten gezeigt:

DROP PROCEDURE IF EXISTS load1;CREATE PROCEDURE load1(count INT UNSIGNED)BEGIN
   DECLARE s INT UNSIGNED DEFAULT 1;
   DECLARE c CHAR(80) DEFAULT REPEAT(&#39;a&#39;,80);   WHILE s <= count DO
      INSERT INTO t1 select NULL,c;
      COMMIT;      SET s=s+1;   END WHILE;END;

Im obigen Beispiel ist es nicht entscheidend, ob der Commit-Befehl hinzugefügt werden soll. Da die Speicher-Engine von MySQL innodb standardmäßig die automatische Übermittlung verwendet, ist das Ergebnis des Entfernens des Commits in der gespeicherten Prozedur dasselbe. Wie unten gezeigt, ist das folgende ein weiteres Problem, das von Entwicklern leicht übersehen wird:

DROP PROCEDURE IF EXISTS load2; CREATE PROCEDURE load2(count INT UNSIGNED)BEGIN
   DECLARE s INT UNSIGNED DEFAULT 1;
   DECLARE c CHAR(80) DEFAULT REPEAT(&#39;a&#39;,80);   WHILE s <= count DO
      INSERT INTO t1 select NULL,c;      SET s=s+1;   END WHILE;END;

Unabhängig von der oben genannten gespeicherten Prozedur bleibt die Datenbank beim Auftreten eines Fehlers an einem unbekannten Ort. Wir möchten beispielsweise 10.000 Daten einfügen, aber beim Einfügen von 5.000 Daten ist ein Fehler aufgetreten. Diese 5.000 Daten sind jedoch bereits in der Datenbank gespeichert. Das andere ist ein Leistungsproblem. Die beiden oben genannten gespeicherten Prozeduren sind nicht schneller als die unten stehende gespeicherte Prozedur, da die folgende eine Einfügung in eine Transaktion einfügt:

DROP PROCEDURE IF EXISTS load3; CREATE PROCEDURE load3(count INT UNSIGNED)BEGIN
   DECLARE s INT UNSIGNED DEFAULT 1;
   DECLARE c CHAR(80) DEFAULT REPEAT('a',80);
   START TRANSACTION;   WHILE s <= count DO
      INSERT INTO t1 select NULL,c;      SET s=s+1;   END WHILE;
   COMMIT;END;

Für die oben genannten drei Speicher Im Prozess: Wir fügen jeweils 1 Million Daten ein, um die Ausführungszeit zu vergleichen, wie unten gezeigt. Es ist offensichtlich, dass die dritte Methode viel schneller ist. Dies liegt daran, dass für jede Erwähnung ein Redo-Protokoll geschrieben werden muss, sodass Load1 und Load2 tatsächlich 1 Million schreiben Redo-Logs. Für die gespeicherte Prozedur „load3“ haben wir das Redo-Log nur einmal geschrieben.

Bereiten Sie zuerst eine Testtabelle vor

CREATE TABLE `t1` (`id` int NOT NULL AUTO_INCREMENT ,`name` varchar(500) NULL ,
PRIMARY KEY (`id`)
) ;

Führen Sie den Test aus

09:50:44 test> call load1(1000000);
Query OK, 0 rows affected (1 min 4.90 sec)09:54:23 test> truncate table t1;
Query OK, 0 rows affected (0.05 sec)09:54:25 test> call load2(1000000);
Query OK, 1 row affected (1 min 3.38 sec)09:55:32 test> truncate table t1;
Query OK, 0 rows affected (0.20 sec)09:55:58 test> call load3(1000000);
Query OK, 0 rows affected (33.90 sec)

Für das zweite Laden der gespeicherten Prozedur2 können wir die Transaktion auch manuell öffnen, das Gleiche gilt Um den Effekt des Ladens der gespeicherten Prozedur zu erzielen, ist die Ausführungszeit wie folgt:

09:57:42 test> begin;
Query OK, 0 rows affected (0.00 sec)09:57:46 test> call load2(1000000);
Query OK, 1 row affected (34.08 sec)09:58:26 test> commit;
Query OK, 0 rows affected (0.76 sec)

2. Informationen zur Verwendung der automatischen Übermittlung

In einigen speziellen Szenarien ist die automatische Übermittlung manchmal nicht unbedingt erforderlich Eine gute Sache. Wie wir oben über das Problem der zirkulären Übermittlung erwähnt haben, verwendet die MySQL-Datenbank standardmäßig die automatische Festschreibung (Autocommit). Sie können die MySQL-Übermittlungsmethode auf folgende Weise ändern:

10:35:34 test> SET AUTOCOMMIT=0;
Query OK, 0 rows affected (0.00 sec)

Sie können auch START TRANSATION oder BEGIN verwenden, um eine Transaktion explizit zu starten. MySQL führt automatisch

SET AUTOCOMMIT=0 und SET AUTOCOMMIT=1 aus, nachdem COMMIT oder ROLLBACK eine Transaktion beendet hat.

3. Verwenden Sie das automatische Rollback, um Ausnahmen zu behandeln. Was ist zu tun, wenn in einem gespeicherten Prozess eine Ausnahme auftritt? Tritt während des Speichervorgangs ein Fehler auf, wird der Rollback-Vorgang automatisch durchgeführt. Als Beispiel unten:

CREATE PROCEDURE sp_auto_rollback_demo()BEGIN
   DECLARE EXIT HANDLER FOR SQLEXCEPTION ROLLBACK;
   START TRANSACTION;
   INSERT INTO b select 1;
   INSERT INTO b select 2;
   INSERT INTO b select 1;
   INSERT INTO b select 3;
   COMMIT;END;

Die Testtabelle lautet wie folgt

CREATE TABLE `b` (  `a` int(11) NOT NULL DEFAULT '0',
  PRIMARY KEY (`a`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8;

Führen Sie die oben gespeicherte Prozedur aus, damit beim Einfügen des zweiten Datensatzes 1 ein Fehler auftritt, aber weil automatisch ist aktiviert Für den Rollback-Vorgang lautet das Ausführungsergebnis dieser gespeicherten Prozedur wie folgt:

10:09:46 test> call sp_auto_rollback_demo;
Query OK, 0 rows affected (0.01 sec)10:10:04 test> select * from b;Empty set (0.00 sec)

Es scheint, dass es kein Problem gibt und der Vorgang relativ normal ist, aber bei der Ausführung von sp_auto_rollback_demo war er erfolgreich oder scheitern? Wir können damit wie folgt umgehen, ein Beispiel ist wie folgt:

DROP PROCEDURE IF EXISTS sp_auto_rollback_demo;CREATE PROCEDURE sp_auto_rollback_demo()BEGIN
   DECLARE EXIT HANDLER FOR SQLEXCEPTION BEGIN ROLLBACK; SELECT -1; END;
   START TRANSACTION;
   INSERT INTO b select 1;
   INSERT INTO b select 2;
   INSERT INTO b select 1;
   INSERT INTO b select 3;
   COMMIT;
   SELECT 1;END;

Wenn ein Fehler auftritt, führen Sie zuerst einen Rollback durch und geben Sie dann -1 zurück, um anzuzeigen, dass während des Betriebs ein Fehler aufgetreten ist. Die Rückgabe von 1 zeigt einen normalen Betrieb an. Die laufenden Ergebnisse lauten wie folgt:

10:16:19 test> call sp_auto_rollback_demo\G*************************** 1. row ***************************-1: -1
1 row in set (0.00 sec)
Query OK, 0 rows affected (0.01 sec)
10:16:35 test> select * from b;
Empty set (0.00 sec)

Das Obige ist der Inhalt der MySQL Innodb-Transaktionsprogrammierprobleme und -verarbeitung. Weitere verwandte Inhalte finden Sie auf der chinesischen PHP-Website (www.php.cn). !