Verwaltetes Verbindungs-Pooling – Übersicht

Mit verwaltetem Verbindungs-Pooling können Sie Ihre Arbeitslasten skalieren, indem Sie die Ressourcennutzung und die Verbindungslatenz für Ihre Cloud SQL-Instanzen optimieren. Beim verwalteten Verbindungs-Pooling wird ein Pool von Threads erstellt, um eingehende Anfragen zu verarbeiten. Dies führt zu erheblichen Leistungsverbesserungen, insbesondere bei skalierten Verbindungen, da plötzliche Verbindungsspitzen abgefangen werden, ohne den Server durch eine Zunahme der Anzahl von Threads zu überlasten.

Weitere Informationen zum Aktivieren des verwalteten Verbindungs-Poolings finden Sie unter Verwaltetes Verbindungs-Pooling konfigurieren.

Voraussetzungen

Damit Sie das verwaltete Verbindungs-Pooling verwenden können, muss Ihre Instanz die folgenden Anforderungen erfüllen:

  • Ihre Instanz muss eine Cloud SQL Enterprise Plus-Instanz sein.
  • Für das verwaltete Verbindungs-Pooling ist eine Mindestwartungsversion von MYSQL_$version.R20250531.01_10 erforderlich. Weitere Informationen zur Durchführung der Self-Service-Wartung finden Sie unter Self-Service-Wartung durchführen.

Erweiterte Konfigurationsoptionen

Sie können das verwaltete Verbindungs-Pooling anpassen, indem Sie die Konfigurationsoption max_pool_size ändern.

Die Option max_pool_size steuert die Nebenläufigkeit für das verwaltete Verbindungs-Pooling. Der Standardwert hängt von der Anzahl der vCPU-Kerne in der Maschinenkonfiguration Ihrer Instanz ab.

Beschränkungen

Wenn Sie Managed Connection Pooling mit Ihren Cloud SQL Enterprise Plus-Instanzen verwenden, beachten Sie die folgenden Einschränkungen:

  • Wenn Sie verwaltetes Verbindungs-Pooling für eine vorhandene Instanz aktivieren, wird die Datenbank neu gestartet.
  • Wenn das verwaltete Verbindungs-Pooling für Ihre Instanz aktiviert ist, wird der Wert des Messwerts thread_cache_size standardmäßig auf 0 gesetzt.

Thread-Pooling im Vergleich zu Verbindungsmultiplexing

In Cloud SQL for MySQL wird für das verwaltete Verbindungs-Pooling ein serverseitiger Thread-Pool anstelle eines externen Verbindungsmultiplexers verwendet:

  • Thread-Pooling (verwaltetes Verbindungs-Pooling): Clients stellen eine direkte Verbindung zum Datenbankserver her, der einen begrenzten Pool von Arbeitsthreads (max_pool_size) wiederverwendet, um Abfragen über aktive Sitzungen hinweg auszuführen, anstatt einen dedizierten Thread pro Verbindung zu erstellen. Dadurch wird der CPU- und Arbeitsspeicheraufwand bei hoher Nebenläufigkeit reduziert. Jede offene Clientverbindung behält jedoch eine dedizierte Serversitzung bei und wird auf das Limit max_connections angerechnet.
  • Verbindungsmultiplexing (z. B. ProxySQL): Clients stellen eine Verbindung über einen Zwischenproxy her, der einen kleineren Pool von Backend-Datenbankverbindungen über viele Clientverbindungen hinweg gemeinsam nutzt. Dadurch wird die Gesamtzahl der offenen serverseitigen Verbindungen direkt reduziert.

Wenn Ihre Arbeitslast die Anzahl der serverseitigen Verbindungen reduzieren muss, um das Limit von max_connections nicht zu erreichen, verwenden Sie einen externen Verbindungspooler wie ProxySQL. Alternativ können Sie das Flag max_connections basierend auf der Speicherkapazität Ihrer Instanz erhöhen.

Nächste Schritte