Anda tidak akan mengetahui status koneksi yang sebenarnya tanpa melalui kabel , dan SELECT 1 adalah kandidat yang cukup baik (bisa dibilang Anda bisa membuat perintah yang lebih pendek yang membutuhkan lebih sedikit waktu untuk menguraikan, tetapi dibandingkan dengan jaringan atau bahkan latensi loopback, penghematan itu tidak signifikan.)
Karena itu, saya berpendapat bahwa melakukan ping ke koneksi sebelum memeriksanya dari kolam bukanlah pendekatan terbaik .
Anda mungkin harus meminta pengelola kumpulan koneksi Anda menerapkan kebijakan keep-alive (batas waktu) sendiri untuk menghindari pemutusan oleh server (singkat dari masalah konektivitas intervensi yang lebih serius, yang dapat mempengaruhi Anda di tengah operasi reguler - dan yang manajer kumpulan koneksi Anda tidak akan dapat membantu), serta
Oleh karena itu dipertanyakan, menurut pendapat saya, apa nilai pengujian untuk kondisi konektivitas sebelum memeriksa koneksi dari kolam yang sebenarnya. Mungkin ada baiknya menguji status koneksi sebelum koneksi diperiksa kembali ke kumpulan , tetapi itu dapat dilakukan secara implisit dengan hanya menandai koneksi sebagai kotor ketika kesalahan keras SQL (atau pengecualian yang setara) muncul (kecuali API yang Anda gunakan sudah memperlihatkan is-bad -seperti panggilan untukmu.)
Oleh karena itu saya akan merekomendasikan:
- menerapkan kebijakan keep-alive sisi klien
- tidak melakukan pemeriksaan apa pun saat memeriksa koneksi dari kumpulan
- melakukan pemeriksaan kotor sebelum koneksi dikembalikan ke pool
- biarkan kode aplikasi menangani kondisi koneksi luar biasa lainnya (non-timeout)
PERBARUI
Tampaknya dari komentar Anda bahwa Anda benar-benar sangat ingin melakukan ping ke koneksi (saya berasumsi itu karena Anda tidak memiliki kendali penuh atas, atau pengetahuan tentang, karakteristik batas waktu pada server MySQL atau peralatan jaringan yang mengganggu seperti proxy, dll.)
Dalam hal ini Anda dapat menggunakan DO 1
sebagai alternatif dari SELECT 1; itu sedikit lebih cepat -- lebih pendek untuk diuraikan, dan tidak mengembalikan data aktual (walaupun Anda akan dapatkan ack TCP s, jadi Anda masih akan melakukan validasi bolak-balik bahwa koneksi masih terjalin.)
PERBARUI 2
Mengenai pos Joshua , inilah jejak pengambilan paket untuk berbagai skenario:
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>
Seperti yang Anda lihat, kecuali fakta bahwa mysql_ping paket adalah 5 byte, bukan DO 1; 9 byte, jumlah perjalanan pulang pergi (dan akibatnya, latensi yang diinduksi jaringan) persis sama. Satu-satunya biaya tambahan yang Anda bayarkan dengan DO 1 sebagai lawan dari mysql_ping adalah penguraian DO 1 , yang sepele.
