Du kommer inte att veta det verkliga tillståndet för anslutningen utan att gå över tråden och SELECT 1 är en tillräckligt bra kandidat (förmodligen skulle du kunna komma på ett kortare kommando som tar mindre tid att analysera, men jämfört med nätverks- eller till och med loopback-latens skulle dessa besparingar vara obetydliga.)
Med detta sagt skulle jag hävda att pinga en anslutning före att kolla upp det från poolen är inte det bästa sättet .
Du borde förmodligen helt enkelt låta din anslutningspoolhanterare upprätthålla sin egen policy för att hålla liv (timeout) för att undvika att bli frånkopplad av servern (kort om ett mer allvarligt mellanliggande anslutningsproblem, som kan påverka dig mitt i ordinarie drift ändå -- och som din anslutningspoolchef ändå inte skulle kunna hjälpa till med), samt för att inte skaka databasen (tänk på filhandtag och minnesanvändning) i onödan.
Det är därför tveksamt, enligt min mening, vilket värdetestning för anslutningsskick innan man checkar ut en anslutning från poolen egentligen har. Det kan vara värt att testa anslutningsstatus innan en anslutning checkas in tillbaka till poolen , men det kan göras implicit genom att helt enkelt markera anslutningen som smutsig när ett SQL-hardt fel (eller motsvarande undantag) uppstår (såvida inte API:et du använder redan avslöjar en is-bad -gilla-samtal för dig.)
Jag skulle därför rekommendera:
- implementera en policy för att hålla vid liv på klientsidan
- inte utför några kontroller när du checkar ut anslutningar från poolen
- utför smutsiga kontroller innan en anslutning återförs till poolen
- låt applikationskoden hantera andra (icke-timeout) exceptionella anslutningsförhållanden
UPPDATERA
Det verkar av dina kommentarer att du verkligen verkligen vill pinga anslutningen (jag antar att det beror på att du inte har full kontroll över, eller kunskap om, timeout-egenskaper på MySQL-servern eller mellanliggande nätverksutrustning såsom proxyservrar etc.)
I det här fallet kan du använda DO 1
som ett alternativ till SELECT 1; det är marginellt snabbare -- kortare att tolka, och det returnerar inte faktiska data (även om du kommer hämta TCP ack s, så du kommer fortfarande att göra tur och retur och verifiera att anslutningen fortfarande är upprättad.)
UPPDATERING 2
Angående Joshuas inlägg , här är paketfångstspår för olika scenarier:
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>
Som du kan se, förutom det faktum att mysql_ping paketet är 5 byte istället för DO 1; s 9 byte är antalet tur och retur (och följaktligen nätverksinducerad latens) exakt detsamma. Den enda extra kostnaden du betalar med DO 1 i motsats till mysql_ping är analysen av DO 1 , vilket är trivialt.