Wie InnoDB die Serialisierungsisolationsebene implementiert

Serialisierungsimplementierung

InnoDB implementiert die Serialisierung auf zwei Arten.

Erstens wird eine LOCK_S-Sperre angewendet, wenn sich die SELECT-Anweisung in einem expliziten Transaktionsblock befindet, z. B. bei der Ausführung von Fallnummer 1 in Tabelle 11-9. Gemäß Tabelle 11-6 (Kompatibilitätstabelle für Datensatzsperren und Transaktionssperren) schließt die LOCK_S-Sperre die Schreibsperre aus, sodass unter der Serialisierungsisolationsebene nur gleichzeitige Lesevorgänge zulässig sind und gleichzeitige Schreibvorgänge verboten sind, wodurch Serialisierbarkeit erreicht wird.

Der entsprechende Code lautet wie folgt:

ha_innobase::external_lock(...)

{...

 wenn (Sperrtyp != F_UNLCK) {

 /* MySQL setzt eine neue Tabellensperre */

...

 if (trx->isolation_level == TRX_ISO_SERIALIZABLE //Serialisierungsisolationsebene && m_prebuilt->select_lock_type == LOCK_NONE

  && thd_test_options(thd, OPTION_NOT_AUTOCOMMIT | OPTION_BEGIN)) { // und innerhalb eines expliziten Transaktionsblocks /* Um eine serialisierbare Ausführung zu erhalten, lassen wir InnoDB konzeptionell 'LOCK IN SHARE MODE' zu allen SELECTs hinzufügen.

  die sonst konsistente Lesevorgänge gewesen wären. Eine Ausnahme sind konsistente Lesevorgänge im Modus AUTOCOMMIT=1:

  wir wissen, dass es sich um schreibgeschützte Transaktionen handelt und dass sie auch serialisiert werden können, wenn sie als konsistente Lesevorgänge ausgeführt werden. */

  m_prebuilt->select_lock_type = LOCK_S; //Lesesperre hinzufügen, d. h. „SPERRE IM FREIGABEMODUS“

  m_prebuilt->stored_select_lock_type = LOCK_S;

 } //Sonst keine Sperre (auch das ist sehr wichtig)

...

 } anders {

 TrxInInnoDB::end_stmt(trx);

 DEBUG_SYNC_C("ha_innobase_end_statement");

 }

...}

Die zweite Möglichkeit, wenn sich die SELECT-Anweisung nicht innerhalb eines expliziten Transaktionsblocks befindet, besteht darin, den neuesten Snapshot (zu Beginn der Transaktion) abzurufen und dann die Daten zu lesen. Da für das konsistente Lesen auf Snapshot-Basis derzeit keine Sperre erforderlich ist, entspricht seine Sperrsituation der Situation entsprechend Nummer 2 in Tabelle 11-9.

Tabelle 11-9 Sperren der Serialisierungsisolationsebene

veranschaulichen:

S0: SELECT * FROM bluesea WHERE c1=2; //Verwende den Primärschlüsselindex als WHERE-Bedingung

Darüber hinaus ist für die Anweisung FLUSH...WITH READ LOCK auch eine Lesesperre LOCK_S unter der Serialisierungsisolationsebene erforderlich.

Der Code lautet wie folgt:

ha_innobase::store_lock(

...

 /* Suche nach FLUSH TABLES ... WITH READ LOCK */

 wenn (trx->Isolationsebene == TRX_ISO_SERIALIZABLE) {

  m_vorgefertigt->select_lock_type = LOCK_S;

  m_prebuilt->stored_select_lock_type = LOCK_S;

 } anders {

  m_prebuilt->select_lock_type = LOCK_NONE;

  m_prebuilt->stored_select_lock_type = LOCK_NONE;

 } 

...

}

Mit der Serialisierung verwandt ist innobase_query_caching_of_table_permitted() . Die Isolationsebene der Serialisierung lässt keine zwischengespeicherten Abfragen zu.

Zusammenfassen

Das Obige ist der vollständige Inhalt dieses Artikels. Ich hoffe, dass der Inhalt dieses Artikels Ihnen bei Ihrem Studium oder Ihrer Arbeit helfen kann. Wenn Sie Fragen haben, können Sie eine Nachricht hinterlassen. Vielen Dank für Ihre Unterstützung von 123WORDPRESS.COM.