Bez přepojení nepoznáte skutečný stav připojení a SELECT 1 je dost dobrý kandidát (pravděpodobně byste mohli přijít s kratším příkazem, jehož analýza zabere méně času, ale ve srovnání s latencí sítě nebo dokonce smyčky by tyto úspory byly zanedbatelné.)
Za těchto okolností bych tvrdil, že ping spojení před kontrolovat to z bazénu není nejlepší přístup .
Pravděpodobně byste měli jednoduše nechat správce fondu připojení vynutit si vlastní zásady zachování (časového limitu) abyste nebyli odpojeni serverem (zkratka vážnějšího problému s konektivitou, který by vás stejně mohl ovlivnit plácnutí uprostřed běžných operací – a se kterým by váš správce fondu připojení stejně nebyl schopen pomoci), stejně jako aby nedošlo k zašpinění databáze (přemýšlejte o zpracování souborů a využití paměti) zbytečně.
Je tedy podle mého názoru otázkou, jakou hodnotu má testování stavu konektivity před odhlášením připojení z poolu skutečně. Možná stojí za to otestovat stav připojení před připojením zpět do fondu , ale to lze provést implicitně jednoduchým označením připojení jako špinavého, když se objeví tvrdá chyba SQL (nebo ekvivalentní výjimka) (pokud vámi používané rozhraní API již nevykazuje is-bad -jako volání pro vás.)
Proto bych doporučil:
- implementace zásady zachování na straně klienta
- neprovádění žádných kontrol při odhlašování připojení z fondu
- provádění špinavých kontrol, než se připojení vrátí do fondu
- nechte kód aplikace vypořádat se s dalšími výjimečnými podmínkami připojení (bez časového limitu)
AKTUALIZACE
Z vašich komentářů by se zdálo, že opravdu skutečně chcete pingnout připojení (předpokládám, že je to proto, že nemáte plnou kontrolu nebo neznáte charakteristiky časového limitu na serveru MySQL nebo zasahujících síťových zařízení, jako jsou proxy atd.)
V tomto případě můžete použít DO 1
jako alternativu k SELECT 1; je to okrajově rychlejší – kratší pro analýzu a nevrací skutečná data (ačkoli budete získat TCP ack s, takže budete stále provádět zpáteční ověření, že je připojení stále navázáno.)
AKTUALIZACE 2
Pokud jde o Joshuův příspěvek , zde jsou stopy zachycení paketů pro různé scénáře:
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>
Jak vidíte, kromě toho, že mysql_ping paket má 5 bajtů místo DO 1; 9 bajtů, počet zpátečních spojení (a následně síťově vyvolaná latence) je přesně stejný. Jediný příplatek, který platíte pomocí DO 1 na rozdíl od mysql_ping je analýza DO 1 , což je triviální.