Heim > Datenbank > MySQL-Tutorial > Leistung und Problemanalyse der MySQL-Transaktionsprogrammierung [Muss für Entwickler gesehen werden]

Leistung und Problemanalyse der MySQL-Transaktionsprogrammierung [Muss für Entwickler gesehen werden]

黄舟
Freigeben: 2017-02-06 10:50:51
Original
1090 Leute haben es durchsucht

Kein Unsinn, voller nützlicher Informationen, gehen Sie direkt zur Analyse:

1. In der Schleife übermittelte Probleme

Viele Entwickler schreiben Transaktionen gerne in der Schleife fest, wie unten gezeigt Ein Beispiel für eine gespeicherte Prozedur, die sie häufig schreiben, lautet wie folgt:

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

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;
Nach dem Login kopieren

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(&#39;a&#39;,80);   
START TRANSACTION;   
WHILE s <= count DO      
INSERT INTO t1 select NULL,c;      
SET s=s+1;   
END WHILE;   
COMMIT;
END;
Nach dem Login kopieren

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`)) ;
Nach dem Login kopieren

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)
Nach dem Login kopieren

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)
Nach dem Login kopieren

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)
Nach dem Login kopieren

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. Automatisches Rollback zur Behandlung von Ausnahmen verwenden

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;
Nach dem Login kopieren

Die Testtabelle lautet wie folgt

CREATE TABLE `b` (  
 `a` int(11) NOT NULL DEFAULT &#39;0&#39;,
  PRIMARY KEY (`a`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8;
Nach dem Login kopieren

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)
Nach dem Login kopieren

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;
Nach dem Login kopieren

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)
Nach dem Login kopieren

Das Obige ist der Inhalt der MySQL-Transaktionsprogrammierungsleistung und Problemanalyse [unbedingt für die Entwicklung lesen]. Weitere verwandte Inhalte finden Sie auf der chinesischen PHP-Website (www.php.cn)!


Quelle:php.cn
Erklärung dieser Website
Der Inhalt dieses Artikels wird freiwillig von Internetnutzern beigesteuert und das Urheberrecht liegt beim ursprünglichen Autor. Diese Website übernimmt keine entsprechende rechtliche Verantwortung. Wenn Sie Inhalte finden, bei denen der Verdacht eines Plagiats oder einer Rechtsverletzung besteht, wenden Sie sich bitte an admin@php.cn
Beliebte Tutorials
Mehr>
Neueste Downloads
Mehr>
Web-Effekte
Quellcode der Website
Website-Materialien
Frontend-Vorlage