Du vil ikke kende den reelle tilstand af forbindelsen uden at gå over ledningen , og SELECT 1 er en god nok kandidat (velsagtens kunne du finde på en kortere kommando, som tager mindre tid at parse, men sammenlignet med netværks- eller endda loopback-latens ville disse besparelser være ubetydelige.)
Når det er sagt, vil jeg påstå, at pinger en forbindelse før at tjekke det ud fra poolen er ikke den bedste fremgangsmåde .
Du skal nok bare få din forbindelsespuljeadministrator til at håndhæve sin egen hold-alive (timeout)-politik for at undgå at blive afbrudt af serveren (kort af et mere alvorligt intervenerende forbindelsesproblem, som alligevel kan påvirke dig midt i almindelig drift -- og som din forbindelsespool manager alligevel ikke ville være i stand til at hjælpe med), samt for ikke at hogge databasen (tænk filhåndtag og hukommelsesbrug) unødvendigt.
Det er derfor efter min mening tvivlsomt, hvilken værdi test af forbindelsestilstand før man tjekker en forbindelse fra poolen egentlig har. Det kan være værd at teste forbindelsesstatus før en forbindelse tjekkes ind i poolen igen , men det kan gøres implicit ved blot at markere forbindelsen som snavset, når en SQL hard fejl (eller tilsvarende undtagelse) opstår (medmindre den API, du bruger, allerede afslører en is-bad -like opkald til dig.)
Jeg vil derfor anbefale:
- implementering af en hold-live-politik på klientsiden
- ikke udfører nogen kontrol, når du tjekker forbindelser fra poolen
- udførelse af beskidte kontroller, før en forbindelse returneres til poolen
- lad applikationskoden håndtere andre (ikke-timeout) ekstraordinære forbindelsesforhold
OPDATERING
Det fremgår af dine kommentarer, at du virkelig virkelig ønsker at pinge forbindelsen (jeg går ud fra, at det skyldes, at du ikke har fuld kontrol over eller kendskab til timeout-karakteristika på MySQL-serveren eller intervenerende netværksudstyr såsom proxyer osv.)
I dette tilfælde kan du bruge DO 1
som et alternativ til SELECT 1; det er marginalt hurtigere -- kortere at parse, og det returnerer ikke faktiske data (selvom du vil få TCP ack s, så du vil stadig foretage rundrejsen og validere, at forbindelsen stadig er etableret.)
OPDATERING 2
Med hensyn til Joshuas indlæg , her er pakkefangstspor for forskellige 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, bortset fra det faktum, at mysql_ping pakken er 5 bytes i stedet for DO 1; 's 9 bytes, er antallet af roundtrips (og følgelig netværksinduceret latens) nøjagtig det samme. Den eneste ekstra omkostning, du betaler med DO 1 i modsætning til mysql_ping er parsing af DO 1 , hvilket er trivielt.