MySQL को विदेशी कुंजी पेश करने से प्रदर्शन कम हो जाता है

Question

मैं रेल 2.3.5 ऐप पर रूबी का निर्माण कर रहा हूं। डिफ़ॉल्ट रूप से, रेल पर रूबी विदेशी कुंजी की बाधा प्रदान नहीं करती है इसलिए मुझे इसे मैन्युअल रूप से करना है। मैं सोच रहा था कि विदेशी कुंजी पेश करने से डाटाबेस पक्ष पर क्वेरी प्रदर्शन कम हो जाता है ताकि इसे करने के लायक न हो। इस मामले में प्रदर्शन मेरी पहली प्राथमिकता है क्योंकि मैं कोड के साथ डेटा स्थिरता की जांच कर सकता हूं। सामान्य रूप से आपकी सिफारिश क्या है? क्या आप विदेशी कुंजी का उपयोग करने की सलाह देते हैं? और आप कैसे सुझाव देते हैं कि मुझे इसे मापना चाहिए?

Answer 1

मान लिया जाये कि: (: InnoDB यानी)

स्तंभों पर अनुक्रमित शामिल आप पहले से ही है

1. आप पहले से ही FKS का समर्थन करता है कि एक भंडारण इंजन का उपयोग कर रहे हैं

तो मुझे लगता है कि आप MySQL लागू अखंडता के द्वारा बेहतर प्रदर्शन प्राप्त करेंगे। रेफरेंसियल अखंडता को लागू करना, आखिरकार, ऐसा कुछ है जो डेटाबेस इंजन को अनुकूलित करने के लिए अनुकूलित किया जाता है। रुबी में अखंडता को प्रबंधित करने के लिए अपना स्वयं का कोड लिखना तुलना में धीमा होने जा रहा है।

यदि आपको एफआई कार्यक्षमता प्राप्त करने के लिए माईसाम से इनो डीबी में स्थानांतरित करने की आवश्यकता है, तो आपको दो इंजनों के बीच प्रदर्शन में ट्रेडऑफ पर विचार करने की आवश्यकता है।

यदि आपके पास पहले से ही नीतियां नहीं हैं, तो आपको यह तय करना होगा कि आप उन्हें चाहते हैं या नहीं। आम तौर पर बोलते हुए, यदि आप लिखने से अधिक पढ़ रहे हैं, तो आप अनिवार्यता (आवश्यकताएं) भी चाहते हैं।

वर्तमान में अनुक्रमित सामग्री के शीर्ष पर एक एफके को ढेर करना आपके आवेदन कोड में उन प्रकार के चेक लागू करने से समग्र प्रदर्शन हिट से कम होना चाहिए।

Answer 2

आम तौर पर, अधिक कुंजी (विदेशी या अन्यथा) INSERT/UPDATE प्रदर्शन को कम कर देगी और चयन प्रदर्शन बढ़ाएगी।

डेटा अखंडता का अतिरिक्त लाभ, आपकी विदेशी कुंजी जोड़ने के साथ आने वाले छोटे प्रदर्शन में कमी के लायक होने की संभावना है। यदि तेज़ डेटा जंक (गुम भागों या आदि) है तो एक तेज़ ऐप कितना अच्छा है?

मिले यहाँ एक समान क्वेरी: Does Foreign Key improve query performance?

Answer 3

आपको विदेशी कुंजी परिभाषित करनी चाहिए। सामान्य रूप से (हालांकि मुझे mySQL के बारे में विशिष्ट जानकारी नहीं है), प्रश्नों पर कोई प्रभाव नहीं पड़ता है (और ओरेकल में लागत आधारित अनुकूलक की तरह एक अनुकूलक होने पर, इसका सकारात्मक प्रभाव भी हो सकता है क्योंकि ऑप्टिमाइज़र पर भरोसा हो सकता है बेहतर पहुंच योजनाओं का चयन करने के लिए विदेशी कुंजी जानकारी)। सम्मिलन और अद्यतन पर प्रभाव के अनुसार, एक प्रभाव हो सकता है, लेकिन आपको प्राप्त होने वाले लाभ (संदर्भित अखंडता और डेटा स्थिरता) प्रदर्शन प्रभाव को बहुत अधिक वजन देते हैं। बेशक, आप एक ऐसी प्रणाली तैयार कर सकते हैं जो बिल्कुल नहीं करेगी, लेकिन मुख्य कारण यह नहीं होगा क्योंकि आपने विदेशी कुंजी जोड़ दी है। और जब आप किसी अन्य भाषा का उपयोग करने का निर्णय लेते हैं तो आपके कोड को बनाए रखने पर असर पड़ता है, या क्योंकि व्यवसाय नियम थोड़ा बदल गए हैं, या क्योंकि एक नया प्रोग्रामर आपकी टीम इत्यादि में शामिल होता है, प्रदर्शन प्रभाव से कहीं अधिक महंगा है। मेरी सिफारिश, फिर, हाँ है, जाओ और विदेशी कुंजी परिभाषित करें। आपका अंतिम उत्पाद अधिक मजबूत होगा।

Answer 4

दो अंक:
1. क्या आप सुनिश्चित हैं कि आवेदन स्तर पर अखंडता की जांच प्रदर्शन के संदर्भ में बेहतर होगी?
2. अपने स्वयं के परीक्षण-परीक्षण को चलाएं यदि एफके के पास प्रदर्शन पर सकारात्मक या नकारात्मक प्रभाव होता है तो यह लगभग मामूली होना चाहिए।

Answer 5

विदेशी कुंजी का उपयोग करना एक अच्छा विचार है क्योंकि यह आपको डेटा स्थिरता का आश्वासन देता है (आप अनाथ पंक्तियों और अन्य असंगत डेटा समस्याओं को नहीं चाहते हैं)।

लेकिन साथ ही साथ एक विदेशी कुंजी जोड़ने से कुछ प्रदर्शन हिट शुरू होती है। मान लें कि आप स्टोरेज इंजन के रूप में INNODB का उपयोग कर रहे हैं, यह पीके के लिए क्लस्टरेड इंडेक्स का उपयोग करता है जहां अनिवार्य रूप से पीके के साथ डेटा संग्रहीत किया जाता है। द्वितीयक सूचकांक का उपयोग कर डेटा तक पहुंचने के लिए द्वितीयक इंडेक्स पेड़ (जहां नोड्स में पीके होता है) पर एक पास की आवश्यकता होती है और फिर डेटा को वास्तव में लाने के लिए क्लस्टर इंडेक्स पर दूसरा पास होता है। तो माता-पिता की मेज पर कोई भी डीएमएल जिसमें एफके शामिल है, को बच्चे की तालिका में इंडेक्स पर दो पास की आवश्यकता होगी। संभोग, प्रदर्शन हिट का प्रभाव डेटा की मात्रा, आपकी डिस्क प्रदर्शन, आपकी स्मृति बाधाओं (डेटा/अनुक्रमणिका कैश) पर निर्भर करता है। तो इसे अपने लक्ष्य तंत्र के साथ दिमाग में मापना सबसे अच्छा है। मैं कहूंगा कि इसे मापने का सबसे अच्छा तरीका आपके नमूना लक्ष्य डेटा के साथ है, या कम से कम आपके सिस्टम के लिए कुछ प्रतिनिधि लक्ष्य डेटा है। फिर एफके बाधाओं के साथ और उसके बिना कुछ मानक चलाने की कोशिश करें। क्लाइंट साइड स्क्रिप्ट लिखें जो दोनों मामलों में एक ही लोड उत्पन्न करती है।

हालांकि, यदि आप मैन्युअल रूप से एफके बाधाओं की जांच कर रहे हैं, तो मैं अनुशंसा करता हूं कि आप इसे mysql तक छोड़ दें और MySQL को इसे संभालने दें।