आप तार पर जाए बिना कनेक्शन की वास्तविक स्थिति नहीं जान पाएंगे , और SELECT 1 एक अच्छा पर्याप्त उम्मीदवार है (यकीनन आप एक छोटी कमांड के साथ आ सकते हैं जिसे पार्स करने में कम समय लगता है, लेकिन नेटवर्क या लूपबैक विलंबता की तुलना में वे बचत महत्वहीन होगी।)
यह कहा जा रहा है, मैं तर्क दूंगा कि एक कनेक्शन पिंग करना पहले पूल से इसकी जांच करना सबसे अच्छा तरीका नहीं है ।
आपके पास शायद बस आपका कनेक्शन पूल मैनेजर होना चाहिए अपनी खुद की कीप-अलाइव (टाइमआउट) नीति लागू करें सर्वर से डिस्कनेक्ट होने से बचने के लिए (एक अधिक गंभीर हस्तक्षेप करने वाली कनेक्टिविटी समस्या से कम, जो आपको नियमित संचालन के बीच में स्मैक को प्रभावित कर सकती है - और जो आपका कनेक्शन पूल मैनेजर वैसे भी मदद करने में असमर्थ होगा), साथ ही साथ <मजबूत>डेटाबेस को हॉग न करने के लिए (फ़ाइल हैंडल और स्मृति उपयोग के बारे में सोचें) अनावश्यक रूप से।
इसलिए यह संदेहास्पद है, मेरी राय में, पूल से कनेक्शन की जांच करने से पहले कनेक्टिविटी की स्थिति के लिए क्या मूल्य परीक्षण वास्तव में है। यह कनेक्शन स्थिति का परीक्षण करने लायक हो सकता है एक कनेक्शन के पूल में वापस चेक इन करने से पहले , लेकिन SQL हार्ड एरर (या समकक्ष अपवाद) उत्पन्न होने पर कनेक्शन को केवल गंदे के रूप में चिह्नित करके यह निहित रूप से किया जा सकता है (जब तक कि आप जिस एपीआई का उपयोग कर रहे हैं वह पहले से ही is-bad को उजागर नहीं करता है। -आपके लिए कॉल की तरह।)
इसलिए मैं अनुशंसा करता हूं:
- क्लाइंट-साइड कीप-अलाइव पॉलिसी को लागू करना
- पूल से कनेक्शन की जाँच करते समय कोई जाँच नहीं करना
- पूल में कनेक्शन वापस करने से पहले गंदी जांच करना
- एप्लिकेशन कोड को अन्य (गैर-टाइमआउट) असाधारण कनेक्शन स्थितियों से निपटने दें
अपडेट करें
आपकी टिप्पणियों से ऐसा प्रतीत होता है कि आप वास्तव में वास्तव में कनेक्शन को पिंग करना चाहते हैं (मुझे लगता है कि ऐसा इसलिए है क्योंकि आपके पास 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 पैकेट DO 1; . के बजाय 5 बाइट्स है के 9 बाइट्स, राउंडट्रिप्स की संख्या (और फलस्वरूप, नेटवर्क-प्रेरित विलंबता) बिल्कुल समान है। केवल अतिरिक्त लागत जो आप DO 1 . के साथ चुका रहे हैं mysql_ping . के विपरीत DO 1 . की पार्सिंग है , जो तुच्छ है।
