Вы не будете знать реальное состояние соединения, не пройдя по проводам , и SELECT 1 является достаточно хорошим кандидатом (возможно, вы могли бы придумать более короткую команду, для анализа которой требуется меньше времени) , но по сравнению с сетью или даже задержкой обратной связи эта экономия была бы незначительной.)
При этом я бы сказал, что проверка связи перед проверкой соединения из пула - не лучший подход .
Вероятно, вам просто нужно, чтобы ваш диспетчер пулов соединений применял свою собственную политику поддержки активности (тайм-аута) , чтобы избежать отключения от сервера (если не считать более серьезной промежуточной проблемы с подключением, которая может повлиять на ваш привкус). в любом случае, в середине обычных операций - и с которыми менеджер пула соединений не сможет помочь в любом случае), а также , чтобы не тратить время на базу данных (думаю, файловые дескрипторы и использование памяти) без необходимости.
Поэтому, на мой взгляд, сомнительно, какое значение имеет тестирование состояния соединения перед проверкой соединения из пула. Возможно, стоит проверить состояние соединения до того, как соединение будет возвращено обратно в пул , но это можно сделать неявно, просто пометив соединение как грязное, когда возникает серьезная ошибка SQL (или эквивалентное исключение) (если только API, который вы используете, уже предоставляет вам is-bad -подобный вызов.)
Поэтому я бы порекомендовал:
- реализация политики поддержания активности на стороне клиента
- не выполняет никаких проверок при проверке соединений из пула
- выполнение грязных проверок перед возвратом соединения в пул
- разрешить коду приложения работать с другими (без тайм-аута) исключительными условиями подключения
UPDATE
Из ваших комментариев может показаться, что вы действительно действительно хотите пропинговать соединение (я полагаю, это из-за того, что вы не имеете полного контроля или не знаете характеристики времени ожидания на сервере MySQL или вмешивающееся сетевое оборудование, такое как прокси и т. д.)
В этом случае вы можете использовать DO 1 в качестве альтернативы SELECT 1; он незначительно быстрее - короче для анализа, и он не возвращает фактические данные (хотя вы получите TCP ack s, так что вы все равно будете проверять, что соединение все еще установлено.)
ОБНОВЛЕНИЕ 2
Относительно сообщения Джошуа , вот следы захвата пакета для различных сценариев:
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 байтов вместо 9 байтов DO 1;, количество циклических возвратов (и, следовательно, задержка, вызванная сетью) точно такое же. Единственная дополнительная плата, которую вы платите DO 1, а не mysql_ping, - это анализ DO 1, что тривиально.