Vous ne connaîtrez pas l'état réel de la connexion sans passer par le fil , et SELECT 1 est un assez bon candidat (vous pourriez sans doute proposer une commande plus courte qui prend moins de temps à analyser, mais par rapport au réseau ou même à la latence de bouclage, ces économies seraient insignifiantes.)
Ceci étant dit, je dirais que pinger une connexion avant le vérifier depuis la piscine n'est pas la meilleure approche .
Vous devriez probablement simplement faire en sorte que votre gestionnaire de pool de connexions applique sa propre politique de maintien en vie (délai d'expiration) pour éviter d'être déconnecté par le serveur (à moins d'un problème de connectivité intermédiaire plus grave, qui pourrait de toute façon vous affecter en plein milieu des opérations régulières - et que votre gestionnaire de pool de connexions ne serait de toute façon pas en mesure d'aider), ainsi que afin de ne pas accaparer la base de données (pensez aux descripteurs de fichiers et à l'utilisation de la mémoire) inutilement.
On peut donc se demander, à mon avis, quelle est la valeur réelle du test de l'état de la connectivité avant de vérifier une connexion depuis le pool. Il peut être utile de tester l'état de la connexion avant qu'une connexion ne soit réenregistrée dans le pool , mais cela peut être fait implicitement en marquant simplement la connexion comme sale lorsqu'une erreur matérielle SQL (ou une exception équivalente) se produit (à moins que l'API que vous utilisez n'expose déjà un is-bad -comme appeler pour vous.)
Je recommanderais donc :
- mise en œuvre d'une politique de maintien d'activité côté client
- n'effectue aucune vérification lors de la vérification des connexions du pool
- effectuer des vérifications erronées avant qu'une connexion ne soit renvoyée au pool
- laisser le code de l'application gérer d'autres conditions de connexion exceptionnelles (sans temporisation)
MISE À JOUR
Il semblerait d'après vos commentaires que vous avez vraiment vraiment voulez envoyer un ping à la connexion (je suppose que c'est parce que vous n'avez pas le contrôle total ou la connaissance des caractéristiques de temporisation sur le serveur MySQL ou sur les équipements réseau intermédiaires tels que les proxys, etc.)
Dans ce cas, vous pouvez utiliser DO 1
comme alternative à SELECT 1; c'est marginalement plus rapide - plus court à analyser, et il ne renvoie pas de données réelles (bien que vous le ferez obtenir le TCP ack s, vous ferez donc toujours l'aller-retour pour valider que la connexion est toujours établie.)
MISE À JOUR 2
Concernant le le message de Joshua , voici les traces de capture de paquets pour différents scénarios :
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>
Comme vous pouvez le voir, à l'exception du fait que le mysql_ping le paquet est de 5 octets au lieu de DO 1; 's 9 octets, le nombre d'allers-retours (et par conséquent, la latence induite par le réseau) est exactement le même. Le seul coût supplémentaire que vous payez avec DO 1 par opposition à mysql_ping est l'analyse de DO 1 , ce qui est trivial.
