Виеняма да разберете реалното състояние на връзката, без да преминете през кабела и SELECT 1 е достатъчно добър кандидат (вероятно бихте могли да измислите по-кратка команда, която отнема по-малко време за синтактичен анализ, но в сравнение с латентността на мрежата или дори обратната верига тези спестявания биха били незначителни.)
Като се има предвид това, бих казал, че пингуването на връзка преди да го проверите от басейна не е най-добрият подход .
Вероятно трябва просто да накарате вашия мениджър на пула на връзки да наложи собствената си политика за поддържане на активност (изчакване) за да избегнете прекъсване на връзката от сървъра (с изключение на по-сериозен проблем със свързаността, който така или иначе може да ви засегне по средата на редовни операции - и за който вашият мениджър на пула за връзки така или иначе не би могъл да помогне), както и за да не се захване базата даннита (помислете за манипулации на файлове и използване на паметта) ненужно.
Следователно е съмнително, според мен, каква стойност наистина има тестването за състояние на свързаност преди проверка на връзка от пула. Може да си струва да тествате състоянието на връзката преди връзката да бъде проверена обратно в пула , но това може да се направи имплицитно, като просто маркирате връзката като мръсна, когато възникне твърда грешка на SQL (или еквивалентно изключение) (освен ако API, който използвате, вече не излага is-bad -харесвам се обаждам за вас.)
Затова бих препоръчал:
- прилагане на политика за поддържане на активност от страна на клиента
- не извършва никакви проверки при проверка на връзки от пула
- извършване на мръсни проверки, преди връзката да бъде върната към пула
- оставете кода на приложението да се справи с други (без изчакване) изключителни условия на връзка
АКТУАЛИЗИРАНЕ
От вашите коментари ще изглежда, че наистина наистина искате да пингувате връзката (предполагам, че това е така, защото нямате пълен контрол или познания за характеристиките на изчакване на MySQL сървъра или намесващо се мрежово оборудване, като прокси сървъри и т.н.)
В този случай можете да използвате DO 1
като алтернатива на SELECT 1; това е пределно по-бързо – по-кратко за анализиране и не връща действителни данни (въпреки че ще вземете TCP ack s, така че все пак ще извършите двупосочното пътуване, потвърждавайки, че връзката все още е установена.)
АКТУАЛИЗИРАНЕ 2
Относно публикацията на Joshua , ето следи за улавяне на пакети за различни сценарии:
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>
Както можете да видите, с изключение на факта, че mysql_ping пакетът е 5 байта вместо DO 1; 9 байта, броят на двупосочните пътувания (и следователно, латентността, предизвикана от мрежата) е абсолютно същата. Единствената допълнителна цена, която плащате с DO 1 за разлика от mysql_ping е синтактичният анализ на DO 1 , което е тривиално.
