Sie werden den wirklichen Status der Verbindung nicht kennen, ohne über die Leitung zu gehen , und SELECT 1 ist ein ausreichend guter Kandidat (Sie könnten sich wohl einen kürzeren Befehl einfallen lassen, dessen Analyse weniger Zeit in Anspruch nimmt, aber im Vergleich zur Netzwerk- oder sogar Loopback-Latenz wären diese Einsparungen unbedeutend.)
Davon abgesehen würde ich argumentieren, dass eine Verbindung vorher angepingt wird es vom Pool aus zu überprüfen, ist nicht der beste Ansatz .
Sie sollten wahrscheinlich einfach Ihren Verbindungspool-Manager seine eigene Keep-Alive-Richtlinie (Zeitüberschreitung) durchsetzen lassen um zu vermeiden, dass die Verbindung zum Server getrennt wird (kurz vor einem schwerwiegenderen dazwischenliegenden Verbindungsproblem, das Sie ohnehin mitten im regulären Betrieb beeinträchtigen könnte – und bei dem Ihr Verbindungspool-Manager ohnehin nicht helfen könnte), sowie um die Datenbank nicht zu belasten (denken Sie an Dateihandles und Speicherverbrauch) unnötig.
Es ist daher meiner Meinung nach fraglich, welchen Wert das Testen des Verbindungszustands vor dem Auschecken einer Verbindung aus dem Pool wirklich hat. Es kann sich lohnen, den Verbindungsstatus zu testen, bevor eine Verbindung wieder in den Pool eingecheckt wird , aber das kann implizit erfolgen, indem die Verbindung einfach als fehlerhaft markiert wird, wenn ein harter SQL-Fehler (oder eine gleichwertige Ausnahme) auftritt (es sei denn, die von Ihnen verwendete API zeigt bereits einen is-bad an). -wie Anruf für Sie.)
Ich würde daher empfehlen:
- Implementieren einer Client-seitigen Keep-Alive-Richtlinie
- keine Überprüfungen beim Auschecken von Verbindungen aus dem Pool durchführen
- Dirty Checks durchführen, bevor eine Verbindung an den Pool zurückgegeben wird
- den Anwendungscode mit anderen außergewöhnlichen Verbindungsbedingungen (ohne Zeitüberschreitung) umgehen lassen
AKTUALISIEREN
Aus Ihren Kommentaren geht hervor, dass Sie wirklich wirklich sind die Verbindung pingen möchten (ich nehme an, das liegt daran, dass Sie keine vollständige Kontrolle über oder Kenntnis von Zeitüberschreitungsmerkmalen auf dem MySQL-Server oder zwischengeschalteten Netzwerkgeräten wie Proxys usw. haben)
In diesem Fall können Sie DO 1 verwenden
als Alternative zu SELECT 1; es ist geringfügig schneller – kürzer zu parsen, und es gibt keine tatsächlichen Daten zurück (obwohl Sie werden Holen Sie sich den TCP ack s, so dass Sie immer noch den Roundtrip durchführen, um zu überprüfen, ob die Verbindung noch hergestellt ist.)
AKTUALISIERUNG 2
In Bezug auf Joshuas Beitrag , hier sind Paketerfassungs-Traces für verschiedene Szenarien:
SELECT 1;
13:51:01.463112 IP client.45893 > server.mysql: P 2270604498:2270604511(13) ack 2531191393 win 1460 <nop,nop,timestamp 2983462950 59680547>
13:51:01.463682 IP server.mysql > client.45893: P 1:57(56) ack 13 win 65306 <nop,nop,timestamp 59680938 2983462950>
13:51:01.463698 IP client.45893 > server.mysql: . ack 57 win 1460 <nop,nop,timestamp 2983462951 59680938>
DO 1;
13:51:27.415520 IP client.45893 > server.mysql: P 13:22(9) ack 57 win 1460 <nop,nop,timestamp 2983488906 59680938>
13:51:27.415931 IP server.mysql > client.45893: P 57:68(11) ack 22 win 65297 <nop,nop,timestamp 59681197 2983488906>
13:51:27.415948 IP client.45893 > server.mysql: . ack 68 win 1460 <nop,nop,timestamp 2983488907 59681197>
mysql_ping
14:54:05.545860 IP client.46156 > server.mysql: P 69:74(5) ack 78 win 1460 <nop,nop,timestamp 2987247459 59718745>
14:54:05.546076 IP server.mysql > client.46156: P 78:89(11) ack 74 win 65462 <nop,nop,timestamp 59718776 2987247459>
14:54:05.546092 IP client.46156 > server.mysql: . ack 89 win 1460 <nop,nop,timestamp 2987247459 59718776>
Wie Sie sehen können, abgesehen von der Tatsache, dass mysql_ping Paket ist 5 Bytes statt DO 1; 's 9 Bytes ist die Anzahl der Roundtrips (und folglich die netzwerkinduzierte Latenz) genau gleich. Die einzigen zusätzlichen Kosten zahlen Sie mit DO 1 im Gegensatz zu mysql_ping ist die Analyse von DO 1 , was trivial ist.
