No sabrás el estado real de la conexión sin pasar por el cable y SELECT 1 es un candidato lo suficientemente bueno (podría decirse que podría crear un comando más corto que tome menos tiempo para analizar, pero en comparación con la red o incluso con la latencia de loopback, esos ahorros serían insignificantes).
Dicho esto, diría que hacer ping a una conexión antes comprobarlo desde la piscina no es el mejor enfoque .
Probablemente debería simplemente hacer que su administrador de grupo de conexiones haga cumplir su propia política de mantenimiento (tiempo de espera) para evitar que el servidor lo desconecte (salvo un problema de conectividad intermedio más serio, que podría afectarlo justo en medio de las operaciones regulares de todos modos, y con el que su administrador de grupo de conexiones no podría ayudarlo de todos modos), así como para no acaparar la base de datos (piense en los identificadores de archivos y el uso de la memoria) innecesariamente.
Por lo tanto, es cuestionable, en mi opinión, qué valor tiene realmente probar la condición de conectividad antes de verificar una conexión del grupo. Puede valer la pena probar el estado de la conexión antes de que una conexión se vuelva a registrar en el grupo , pero eso se puede hacer implícitamente simplemente marcando la conexión como sucia cuando surge un error grave de SQL (o una excepción equivalente) (a menos que la API que está utilizando ya exponga un is-bad -como llamar por ti.)
Por lo tanto, recomendaría:
- implementación de una política de supervivencia del lado del cliente
- no realizar ninguna comprobación al comprobar las conexiones del grupo
- realizar comprobaciones sucias antes de que se devuelva una conexión al grupo
- deje que el código de la aplicación se ocupe de otras condiciones de conexión excepcionales (sin tiempo de espera)
ACTUALIZAR
De tus comentarios parecería que realmente realmente desea hacer ping a la conexión (supongo que se debe a que no tiene control total ni conocimiento de las características de tiempo de espera en el servidor MySQL o en el equipo de red que interviene, como proxies, etc.)
En este caso puedes usar DO 1
como alternativa a SELECT 1; es marginalmente más rápido, más corto de analizar y no devuelve datos reales (aunque lo hará obtener el TCP ack s, por lo que seguirá haciendo el viaje de ida y vuelta validando que la conexión aún está establecida).
ACTUALIZACIÓN 2
Con respecto a publicación de Joshua , aquí hay rastros de captura de paquetes para varios escenarios:
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>
Como puede ver, excepto por el hecho de que mysql_ping el paquete tiene 5 bytes en lugar de DO 1; Con los 9 bytes de , el número de viajes de ida y vuelta (y, en consecuencia, la latencia inducida por la red) es exactamente el mismo. El único costo adicional que está pagando con DO 1 a diferencia de mysql_ping es el análisis de DO 1 , lo cual es trivial.
