एसक्यूएल सर्वर प्रदर्शन - यदि चयन + अद्यतन बनाम अद्यतन

Question

मैं एक बड़ी स्क्रिप्ट, अद्यतन बयान है कि दैनिक चलेंगे से भरा लिख ​​रहा हूँ। इनमें से कुछ अपडेट पंक्तियों को प्रभावित करेंगे जो दूसरों को नहीं करेंगे।

मुझे विश्वास है कि अद्यतन बयान है कि कुछ भी प्रभावित नहीं करेगा बहुत अच्छा अभ्यास नहीं है, लेकिन मेरे सवाल यह है:

• कैसे बुरी तरह से इस प्रदर्शन को प्रभावित कर सकते हैं ?? क्या चयन चुनने और केवल कुछ चुनने के बाद ही यह बहुत अलग है?

धन्यवाद, टैगो

Answer 1

यह निर्भर करता है आप कैसे अद्यतन कर रहे हैं। आप में शामिल हो गए वाक्य रचना (अर्थात) का उपयोग कर अपडेट कर रहे हैं

UPDATE targetTable 
FROM targetTable INNER JOIN sourceTable 

तो फिर तुम सुंदर बस जहां केवल करने के लिए खंड पंक्ति को अद्यतन करता है, तो मान आप सेट करना चाहते वास्तव में अलग हैं जोड़ सकते हैं।

और हाँ, यह प्रदर्शन को प्रभावित कर सकते हैं, खासकर यदि आपको लगता है कि कुछ इस तरह विचार करें ...

UPDATE targetTable SET column = column 

... एक ट्रिगर है कि अद्यतन पर परिभाषित किया गया था निकाल देते थे। मैं इस पर 100% नहीं हूं, लेकिन मेरा मानना ​​है कि यह लेनदेन लॉग में भी करता है क्योंकि इसे लॉग पूंछ बैकअप और मिररिंग लक्ष्यों के क्रम में बनाए रखने की आवश्यकता होती है ताकि वे घटनाओं के अनुक्रम को पूरी तरह से टुकड़े कर सकें।

Answer 2

तुम वहाँ प्रदर्शन के मामले में UPDATE … WHERE condition और SELECT … WHERE the_same_condition + UPDATE … WHERE the_same_condition के बीच एक अंतर है कि क्या पूछने के लिए मतलब है, तो मैं नहीं बल्कि बाद पूर्व की तुलना में कम कुशल होने की अपेक्षा करेंगे। चाहे वह UPDATE या SELECT है, पंक्तियों अभी भी पता लगा लिया जायेगा, और प्रारंभिक SELECT … WHERE … साथ वे अगर वहाँ एक हिट फिल्म साबित हुई दो बार पता लगा लिया जायेगा।

लेकिन @Matt Whitfield has got a point ट्रिगर के बारे में। यदि अद्यतन पर कोई ट्रिगर है, तो यह किसी भी पंक्ति को अपडेट किए जाने के बावजूद आग लग जाएगी। और वहाँ कुछ है अगर ट्रिगर करता है भले ही कोई पंक्तियों अद्यतन कर रहे हैं (और आप उस से बचने के लिए चाहते हैं), तो या तो अपने ट्रिगर को फिर से लिखने या, हाँ, SELECT + UPDATE दृष्टिकोण के साथ चलते हैं।

Answer 3

सबसे पहले, चयन अद्यतन के बाद लगभग हमेशा संगामिति के तहत गलत है। जब तक चीजें SERIALIZABLE अलगाव स्तर के तहत नहीं चलती हैं, तब तक कोई गारंटी नहीं है कि पंक्तियां के बीच चयन और अद्यतन के बीच नहीं बदलती हैं।

दूसरा, उन मामलों के लिए जब पंक्तियों को अद्यतन करने के लिए हैं, तो चयन + अद्यतन की लागत केवल एक अद्यतन से अधिक परिभाषा है।

और आखिरी, मामले के लिए जब वहाँ उन्हें अद्यतन द्वारा पता लगाने की लागत को अद्यतन करने के पंक्तियों नहीं हैं अक्सर उन्हें चयन से पता लगाने की लागत के रूप में ही है, तो आप कुछ भी हासिल नहीं किया। मैं अक्सर 'नहीं' कहता हूं, 'हमेशा' नहीं, क्योंकि क्वेरी ऑप्टिमाइज़र अद्यतन बनाम चयन के लिए अलग-अलग रणनीतियों पर विचार कर सकता है और पढ़ने के लिए स्कैन की तुलना में अद्यतन के लिए स्कैन अलग लॉकिंग (समवर्ती) नियमों के तहत होता है।

क्या समझ सकता है कि एक बहुत ही सस्ता चयन है जो महंगी अद्यतन से बच सकता है, भले ही 100% सटीक न हो। चयन और अद्यतन के बीच की स्थिति जंगली रूप से भिन्न हो सकती है जब तक आपको कोई झूठी नकारात्मक न हो (चयन करें कि कोई पंक्ति नहीं होनी चाहिए लेकिन अद्यतन को पंक्ति मिली होगी, इसे चलाया गया था) और झूठी संख्या सकारात्मक कम है (चयन कहता है कि पंक्तियां हैं, लेकिन अधिक सटीक/महंगा अद्यतन चेक वास्तव में कोई नहीं ढूंढता है)।

आखिरकार यह अनुकूलन की समस्या है और सभी अनुकूलन प्रश्न मापने से शुरू होते हैं। पहले महंगा अद्यतन का पता लगाएं और फिर संशोधित करना प्रारंभ करें।