🏗️Architektur und Verbindungsaufbau

Was passiert zwischen „Verbindung öffnen“ und der ersten Ergebniszeile? Erst das Protokoll, dann die SQL-Schicht, zuletzt die Storage Engine.

🤝Verbindungsaufbau Schritt für Schritt

Das MariaDB-Protokoll ist kompatibel zum MySQL-Protokoll. Die Bytes unten werden im Browser berechnet – auch die SHA-1-Antwort von mysql_native_password.

Passwort des Clients

Das Konto ist mit dem Beispielpasswort beispiel-passwort angelegt. Tippe ein anderes – alle Hashes werden live neu berechnet.

Schritt 1 / 10 · Tasten ← →

Client────────▶MariaDB-Server

TCP-Verbindung

Der Client öffnet eine TCP-Verbindung zu Port 3306 (oder zum Unix-Socket). Noch hat niemand ein Byte MariaDB-Protokoll gesendet – der Server spricht zuerst.

🧵Ein Thread pro Verbindung oder Thread-Pool?

one-thread-per-connection (Standard unter Unix)

Verbindung 1 ──▶ Thread 1
Verbindung 2 ──▶ Thread 2
   …                …
Verbindung 900 ─▶ Thread 900   ← viele schlafen,
                                 alle kosten Stack + Kontextwechsel

Einfach und schnell bei wenigen Verbindungen. Bei Tausenden gleichzeitig aktiver Verbindungen bremsen Kontextwechsel und Speicher.

pool-of-threads (Thread-Pool)

Verbindungen ─▶ Gruppe 1 [Listener] ─▶ Worker a, b
             ─▶ Gruppe 2 [Listener] ─▶ Worker c
             ─▶ …   (thread_pool_size = Anzahl CPUs)
Timer: hängt eine Gruppe länger als thread_pool_stall_limit
       (500 ms), darf ein weiterer Worker starten

Einschalten mit thread_handling=pool-of-threads in der my.cnf. In MariaDB fest eingebaut – bei MySQL gibt es den Thread-Pool nur in der kommerziellen Enterprise-Edition.

🛤️Der Weg einer Abfrage

SELECT name FROM kunden WHERE id = 7 – von der Verbindung über Parser, Optimizer und Executor bis in den B+-Baum von InnoDB.

Verbindung→

Parser→

Präprozessor→

Optimizer→

Executor→

Handler-API→

InnoDB→

Antwort

Schritt 1 / 8 · Tasten ← →

Paket kommt an

Der Thread der Verbindung liest ein COM_QUERY-Paket vom Socket.

COM_QUERY  "SELECT name FROM kunden WHERE id = 7"

🧰Storage Engines im Überblick

Die Engine wird pro Tabelle gewählt: CREATE TABLE … ENGINE=InnoDB. Verfügbare Engines zeigt SHOW ENGINES.

Engine	Transaktionen	Sperren	Fremdschlüssel	Nach Absturz	Typischer Einsatz
InnoDB	✅ ACID	Zeile	✅	✅ Redo-Log	Standard für fast alles
Aria	–	Tabelle	–	✅ eigenes Log	Systemtabellen, interne Temp-Tabellen
MyISAM	–	Tabelle	–	– (REPAIR TABLE)	Altbestand, nur lesen
MEMORY	–	Tabelle	–	– (nach Neustart leer)	kleine Nachschlagetabellen
ColumnStore	ja (eigenes Versionsmodell)	–	–	✅	Analysen über große Datenmengen (Spalten statt Zeilen)
Spider	über XA	entfernt	–	entfernt	Tabelle über mehrere Server verteilen (Sharding)

💡 Engine-Wechsel

ALTER TABLE t ENGINE=InnoDB; baut die Tabelle komplett neu auf. Bei großen Tabellen dauert das und braucht doppelten Platz.

✅ Faustregel

Nimm InnoDB, solange es keinen klaren Grund dagegen gibt. ColumnStore und Spider lösen Spezialprobleme (Analytik, Verteilung).