有線を経由しないと接続の実際の状態を知ることはできずSELECT 1、十分な候補です（おそらく、解析にかかる時間が短い短いコマンドを思い付くことができますが、ネットワークやループバックの遅延と比較しても、これらの節約は重要ではありません。）
そうは言っても、プールからチェックアウトする前に接続にpingを実行するのは最善の方法ではないと私は主張します。
サーバーによって切断されないように、接続プールマネージャーに独自のキープアライブ（タイムアウト）ポリシーを適用させる必要があります（とにかく通常の操作の途中でスマックに影響を与える可能性のある、より深刻な接続の問題が発生する場合を除きます-そして、接続プールマネージャーはとにかく助けることができないでしょう）、そしてデータベースを不必要に占有しないようにするために（ファイルハンドルとメモリ使用量を考えてください）。
したがって、私の意見では、プールから接続をチェックアウトする前に接続状態をテストする価値が実際にどのようなものであるかは疑問です。接続がプールにチェックインされる前に接続ステータスをテストする価値があるかもしれませんが、SQLハードエラー（または同等の例外）が発生したときに接続をダーティとしてマークするだけで暗黙的に行うことができます（すでに使用しているAPIを除く）のis-badような呼び出しを公開します。）
したがって、私はお勧めします：
- クライアント側の維持ポリシーの実装
- プールから接続をチェックアウトするときにチェックを実行しない
- 接続がプールに返される前にダーティチェックを実行する
- アプリケーションコードに他の（タイムアウトではない）例外的な接続条件を処理させます
アップデート
コメントから、本当に接続にpingを実行したいように見えます（これは、MySQLサーバーまたはプロキシなどの介在するネットワーク機器のタイムアウト特性を完全に制御または認識していないためだと思います）。
この場合、 ;DO 1の代わりに使用できます。わずかにSELECT 1高速です。解析が短く、実際のデータは返されません（ただし、TCPを取得するため、接続がまだ確立されていることを検証するラウンドトリップを実行します）。ack
更新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パケットがDO 1;9バイトではなく5バイトであるという事実を除けば、ラウンドトリップの数（およびその結果としてネットワークに起因する遅延）はまったく同じです。DO 1とは対照的に、あなたが支払っている唯一の追加費用mysql_pingは、の解析ですDO 1。これは些細なことです。