Warum erscheinen ausgewählte @@session.tx_read_only in großen Mengen in der Datenbank?

Finden Sie das Problem

Beim Abrufen der wichtigsten SQL-Anweisungen stellte ich fest, dass die Datenbank eine große Anzahl select @@session.tx_read_only -Anweisungen ausführte. Diese Anweisung erschien vor fast jeder DML-Anweisung. Die Anwendungsschicht führt jedoch keine spezielle Verarbeitung durch. Was ist also der Zweck dieser SQL-Anweisung? Wer hat es ausgeführt?

Detaillierte Einführung

Die Hauptfunktion dieses SQL besteht darin, zu bestimmen, ob es sich bei der Transaktion um eine schreibgeschützte Transaktion handelt. MySQL selbst optimiert schreibgeschützte Transaktionen, was erst nach MySQL-Version 5.6.5 möglich ist. http://dev.mysql.com/doc/refman/5.6/en/server-system-variables.html#sysvar_tx_read_only

Suchen Sie das MySQL-Treiberpaket

ConnectionImpl.java:

Wie Sie sehen, wird in der if-Bedingung die MySQL-Version beurteilt, und es gibt auch eine Bedingung !getUseLocalSessionState() , die dem JDBC-Parameter useLocalSessionState entspricht. Wenn dieser Wert falsch ist, wird die SQL- select @@session.tx_read_only ; ausgegeben.

Standardmäßig enthalten unsere Verbindungszeichenfolgeninformationen nicht die Einstellung des Parameters useLocalSessionState und dieser Wert ist standardmäßig auf „false“ eingestellt.

Dieser Wert bestimmt, ob der Treiber die internen Werte von Autocommit, Read_Only und Transaktionsisolation (lokale Werte auf der JDBC-Seite) verwendet.

Wenn der Wert auf „false“ gesetzt ist, müssen in den Szenarien, in denen diese drei Parameter beurteilt werden müssen, Anweisungen an die Remote-Anforderung gesendet werden, z. B. vor dem Aktualisieren der Anweisung.

Sie müssen die Anweisung select @@session.tx_read_only ausgeben, um zu bestätigen, ob die Sitzung schreibgeschützt ist.

Wenn auf „true“ gesetzt, muss nur der lokale Wert übernommen werden. Dies kann erklären, warum einige Instanzen viele select @@session.tx_read_only -Anweisungen haben.

Im Allgemeinen kann der Treiber sicherstellen, dass der lokale Wert mit dem Wert des Remote-Servers übereinstimmt. Wenn die Anwendung die Schnittstellen setAutoCommit, setTransactionIsolation und setReadOnly aufruft, um Parameterwerte festzulegen, wird sie mit dem Remote-Server synchronisiert.

Speziell,

Wenn useLocalSessionState wahr ist und der Wert nicht mit dem lokalen Wert übereinstimmt, wird er an das Remote-Update gesendet.

Wenn useLocalSessionState falsch ist, wird es jedes Mal an das Remote-Update gesendet, unabhängig davon, ob der festgelegte Wert mit dem lokalen Wert übereinstimmt. Dies könnte erklären, warum einige Instanzen mehr festgelegte Autocommit-Anweisungen haben.

Wenn der Benutzer die Parameter jedoch nicht über die JDBC-Schnittstelle (z. B. „setAutoCommit“) festlegt, sondern句'set autocommit=xxx' ausführt, treten Inkonsistenzen zwischen dem lokalen Wert und dem Remote-Wert auf, was dazu führen kann, dass sich die Geschäftslogik ändert, nachdem der Parameter „useLocalSessionState“ geändert wurde.

Zugehörige SQL-Anweisungen zu Einstellungen:

set autocommit=0 /*Setze den Auto-Commit-Modus der Sitzung*/ Entsprechende JDBC-Schnittstelle: setAutoCommit(false)
set tx_isolation='read-committed' /*Isolationsebene für Transaktionen festlegen*/ Entsprechende JDBC-Schnittstelle: setTransactionIsolation('read-committed') 
set tx_read_only=0; /*Schreibgeschützte Transaktion festlegen*/ Entsprechende JDBC-Schnittstelle: setReadOnly(false)

Das Festlegen des Standardwerts von useLocalSessionState auf „true“ kann zu Bedeutungsänderungen in der Geschäftslogik führen. Die Auslösebedingung besteht darin, dass der Benutzer den Auto-Commit-Parameter, den Isolationsebenenparameter oder den schreibgeschützten Transaktionsparameter direkt über SQL-Anweisungen festlegt.

Zusammenfassen

Das Obige ist der vollständige Inhalt dieses Artikels. Ich hoffe, dass der Inhalt dieses Artikels einen gewissen Lernwert für Ihr Studium oder Ihre Arbeit hat. Wenn Sie Fragen haben, können Sie eine Nachricht hinterlassen. Vielen Dank für Ihre Unterstützung von 123WORDPRESS.COM.