क्या एक गतिशील एसक्यूएल संग्रहीत प्रक्रिया बहुत सारे रिकॉर्ड के लिए एक बुरी चीज है?

Question

मेरे पास लगभग 800,000 रिकॉर्ड वाली एक टेबल है और मैं वर्तमान में बैक एंड पर क्वेरी जेनरेट करने के लिए गतिशील एसक्यूएल का उपयोग कर रहा हूं। फ्रंट एंड एक खोज पृष्ठ है जिसमें लगभग 20 पैरामीटर लगते हैं और पैरामीटर चुना गया था या नहीं, यह आधार क्वेरी में "AND ..." जोड़ता है। मैं उत्सुक हूं कि गतिशील एसक्यूएल जाने का सही तरीका है (ऐसा प्रतीत नहीं होता क्योंकि यह धीमा चलता है)। मैं बस अपने सभी डेटा के साथ एक denormalized टेबल बनाने पर विचार कर रहा हूँ। क्या यह एक अच्छा विचार है या क्या मुझे गतिशील एसक्यूएल का उपयोग करके टुकड़े के टुकड़े के निर्माण के बजाय सभी को एक साथ क्वेरी बनाना चाहिए। आखिरी बात, गतिशील एसक्यूएल को गति देने का कोई तरीका है?

Answer 1

यह अधिक संभावना है कि आपकी अनुक्रमणिका (या इसकी कमी) गतिशील एसक्यूएल की तुलना में धीमी हो रही है।

निष्पादन योजना कैसा दिखता है? एसएसएमएस में निष्पादित होने पर वही क्वेरी धीमी होती है? संग्रहीत प्रक्रिया में कब होता है इसके बारे में क्या?

यदि आपकी तालिका एक अनियंत्रित ढेर है, तो यह खराब प्रदर्शन करेगा क्योंकि रिकॉर्ड्स की संख्या बढ़ती है - यह क्वेरी के बावजूद है, और गतिशील क्वेरी वास्तव में तालिका प्रकृति में बदलाव के रूप में बेहतर प्रदर्शन कर सकती है क्योंकि गतिशील क्वेरी अधिक संभावना है कैश में नहीं होने पर इसकी क्वेरी प्लान का पुनः मूल्यांकन किया जाना चाहिए। यह सामान्य रूप से एक मुद्दा नहीं है (और मैं इसे गतिशील प्रश्नों के डिज़ाइन लाभ के रूप में वर्गीकृत नहीं करता) सिवाय जब एसपी को पुन: संकलित नहीं किया जाता है, लेकिन आंकड़ों और क्वेरी योजनाओं की तारीख समाप्त हो जाती है, लेकिन वॉल्यूम की मात्रा डेटा अभी काफी बदल गया है।

अभी तक स्थिर नहीं है। मेरे पास गतिशील क्वेरी है, लेकिन यह कोई अनुकूलन नहीं देता है। अगर मैंने इसे स्थिर क्वेरी के साथ चलाया और सुझाव दिए, तो क्या उन्हें लागू करने से गतिशील क्वेरी प्रभावित होगी? - Xaisoft (41 मिनट पहले)

हां, गतिशील क्वेरी (EXEC (@sql)) का विश्लेषण तब तक नहीं किया जा रहा है जब तक आप वर्कलोड फ़ाइल का विश्लेषण नहीं करते। - कैड रूक्स (33 मिनट पहले)

जब आपके पास शामिल होने वाली कई तालिकाओं में एक खोज क्वेरी है, तो इंडेक्स वाले कॉलम खोज कॉलम के साथ-साथ प्राथमिक कुंजी/विदेशी कुंजी कॉलम होने की आवश्यकता होती है - लेकिन यह इस पर निर्भर करती है विभिन्न तालिकाओं की कार्डिनालिटी। ट्यूनिंग विश्लेषक इसे दिखाना चाहिए। - कैड रॉक्स (22 मिनट पहले)

Answer 2

पैरामीटर वैकल्पिक हैं, तो एक चाल है कि अक्सर इस्तेमाल इस तरह की एक प्रक्रिया बनाने के लिए है:

CREATE PROCEDURE GetArticlesByAuthor (
    @AuthorId int, 
    @EarliestDate datetime = Null) 
AS 
    SELECT * --not in production code! 
    FROM Articles 
    WHERE AuthorId = @AuthorId 
    AND (@EarliestDate is Null OR PublishedDate < @EarliestDate) 

Answer 3

"डायनामिक" और "स्थिर" एसक्यूएल के बीच फर्क सिर्फ इतना है पार्सिंग/अनुकूलन चरण है। एक बार ऐसा करने के बाद, क्वेरी समान रूप से चल जाएगी।

सरल प्रश्नों के लिए, यह पार्सिंग चरण प्लस नेटवर्क यातायात कुल लेनदेन समय का एक महत्वपूर्ण प्रतिशत साबित होता है, इसलिए इन बार कोशिश करने और कम करने का अच्छा अभ्यास है।

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

मैं क्वेरी को अनुकूलित करने पर ध्यान केंद्रित करूंगा, जिसमें शायद आपको लगता है कि यह उचित है, हालांकि मैं इसे अपने आस-पास के पहले जाने पर नहीं कर सकता।

कभी-कभी कैश किए गए लुकअप टेबल का उपयोग करके एप्लिकेशन में "रन टाइम" पर denormalization किया जा सकता है, उदाहरण के लिए, डेटाबेस को बनाए रखने के बजाय।

Answer 4

पिछले उत्तर के रूप में, अपनी अनुक्रमणिका और योजना की जांच करें।

सवाल यह है कि क्या आप एक संग्रहीत प्रक्रिया का उपयोग कर रहे हैं। यह जिस तरह से आपने इसे बताया है उससे स्पष्ट नहीं है। एक संग्रहित प्रक्रिया चलाने पर एक क्वेरी योजना बनाता है, और उस योजना को फिर से संकलित किए बिना रखता है। अलग-अलग एसक्यूएल के साथ, आप एक खराब क्वेरी योजना से फंस सकते हैं। आप कई चीजें कर सकते हैं:

1) एसपी परिभाषा के लिए रिकॉम्प्ली के साथ जोड़ें, जो प्रत्येक निष्पादन के साथ एक नई योजना उत्पन्न की जाएगी। इसमें कुछ ओवरहेड शामिल हैं, जो स्वीकार्य हो सकते हैं।

2) प्रदान किए गए पैरामीटर के आधार पर अलग एसपी का उपयोग करें। यह बेहतर क्वेरी प्लान कैशिंग

3) क्लाइंट जेनरेट किए गए SQL का उपयोग करने की अनुमति देगा। यह प्रत्येक बार एक प्रश्न योजना तैयार करेगा। यदि आप पैरामीटरयुक्त प्रश्नों का उपयोग करते हैं, तो यह आपको कैश्ड क्वेरी योजनाओं का उपयोग करने की अनुमति दे सकता है।

Answer 5

यहाँ वैकल्पिक खोज मानदंड से प्रश्नों के कुछ अच्छे उदाहरण हैं: How do I create a stored procedure that will optionally search columns?

Answer 6

बताया गया है, यदि आप एक बड़े पैमाने पर क्वेरी कर रहे हैं, इंडेक्स पहले टोंटी को देखने के लिए कर रहे हैं। सुनिश्चित करें कि भारी पूछे जाने वाले कॉलम अनुक्रमित हैं। साथ ही, सुनिश्चित करें कि आपकी क्वेरी सभी अनुक्रमित पैरामीटर को अन-अनुक्रमित पैरामीटर की जांच करने से पहले जांचती है। यह सुनिश्चित करता है कि परिणाम पहले इंडेक्स का उपयोग करके फ़िल्टर किए जाते हैं और फिर धीमी रैखिक खोज केवल तभी होती है जब इसे करना पड़ता है। तो अगर col2 अनुक्रमित लेकिन है col1, नहीं है, यह इस प्रकार दिखना चाहिए:

WHERE col2 = @col2 AND col1 = @col1 

आप परीक्षा जा सकता है के रूप में अच्छी तरह से अनुक्रमित के साथ पानी में गिर जाते हैं, लेकिन ध्यान रखें कि बहुत से अनुक्रमित धीमी राईट और बड़े पैमाने पर डिस्क पैदा कर सकता है उपयोग, तो बहुत पागल मत जाओ।

यदि मैं दो कारणों से कर सकता हूं तो मैं गतिशील प्रश्नों से बचता हूं। एक, वे क्वेरी प्लान को सहेजते नहीं हैं, इसलिए कथन प्रत्येक बार संकलित हो जाता है। दूसरा यह है कि उन्हें कुशलतापूर्वक परीक्षण, परीक्षण और समस्या निवारण करना मुश्किल होता है। (वे सिर्फ बदसूरत लग रहे हैं)।

मुझे ऊपर Dave Kemp's answer पसंद है।

Answer 7

मैं बस का कहना है कि यदि आप वैकल्पिक पैरामीटर की इस शैली का उपयोग करना चाहते हैं:

AND (@EarliestDate is Null OR PublishedDate < @EarliestDate) 

क्वेरी अनुकूलक कि क्या पैरामीटर वहाँ है या नहीं, जब यह क्वेरी योजना का उत्पादन पता नहीं होगा। मैंने ऐसे मामलों को देखा है जहां इन मामलों में अनुकूलक खराब विकल्प बनाता है। एक बेहतर समाधान एसक्यूएल का निर्माण करना है जो केवल आपको आवश्यक पैरामीटर का उपयोग करता है। इन मामलों में अनुकूलक सबसे कुशल निष्पादन योजना बना देगा। पैरामीटरयुक्त प्रश्नों का उपयोग करना सुनिश्चित करें ताकि वे योजना कैश में पुन: प्रयोज्य हो सकें।

Answer 8

नहीं

गतिशील Sql के एक प्रशंसक है, लेकिन अगर आप इसके साथ फंस रहे हैं, तो आप शायद इस लेख पढ़ना चाहिए: http://www.sommarskog.se/dynamic_sql.html वह वास्तव में गतिशील एसक्यूएल और isues का उपयोग कर इसे बना सकते हैं उपयोग करने के लिए सर्वोत्तम उपाय है पर गहराई में चला जाता है।

जैसा कि अन्य ने कहा है, अनुक्रमण सबसे संभावित अपराधी है। अनुक्रमण में, एक चीज जो लोग अक्सर भूल जाते हैं वह एफके क्षेत्रों पर एक सूचकांक डालता है। चूंकि एक पीके स्वचालित रूप से एक इंडेक्स बनाता है, इसलिए कई लोग एक एफके भी मानेंगे। दुर्भाग्य से एक एफके बनाना एक सूचकांक बनाने के लिए करता है। तो सुनिश्चित करें कि आपके द्वारा शामिल किए गए किसी भी फ़ील्ड को अनुक्रमित किया गया है।

आपके गतिशील एसक्यूएल बनाने के बेहतर तरीके हो सकते हैं लेकिन कोड को देखे बिना यह कहना मुश्किल है। मैं कम से कम यह देखने के लिए देखता हूं कि यह सबक्वायरीज़ का उपयोग कर रहा है और इसके बजाय व्युत्पन्न तालिका के साथ उन्हें प्रतिस्थापित करता है। कर्सर का उपयोग करने वाला कोई गतिशील एसक्यूएल भी धीमा होना चाहिए।

Answer 9

मैं निम्नलिखित तर्क के साथ कुछ सफलता (उदाहरणों की एक सीमित संख्या में) मिला है:

CREATE PROCEDURE GetArticlesByAuthor ( 
    @AuthorId int,  
    @EarliestDate datetime = Null 
    ) AS 

SELECT SomeColumn 
FROM Articles 
WHERE AuthorId = @AuthorId 
AND @EarliestDate is Null 
UNION 
SELECT SomeColumn 
FROM Articles 
WHERE AuthorId = @AuthorId 
AND PublishedDate < @EarliestDate 

Answer 10

आप 1s सीमा से नीचे करने के लिए अनुकूलन करने के लिए कोशिश कर रहे हैं, तो इसमें लगभग गेज कैसे करने के लिए महत्वपूर्ण हो सकता है

SET STATISTICS TIME ON; 

और फिर गतिशील एसक्यूएल स्ट्रिंग "स्थिर" निष्पादित और "संदेश" टैब की जाँच करें: तक यह पार्स करने के लिए और संकलन वास्तविक क्वेरी निष्पादन समय के लिए गतिशील एसक्यूएल रिश्तेदार लेता है। मैं एक ~ 10 लाइन गतिशील एसक्यूएल क्वेरी कि एक 1M पंक्ति तालिका से दो पंक्तियों रिटर्न के लिए इन परिणामों से आश्चर्यचकित था:

SQL Server parse and compile time: 
    CPU time = 199 ms, elapsed time = 199 ms. 

(2 row(s) affected) 

SQL Server Execution Times: 
    CPU time = 0 ms, elapsed time = 4 ms. 

सूचकांक अनुकूलन doubtfully कुछ analyzation/अनुकूलन शामिल की वजह से ज्यादा (शायद छोड़कर 199ms बाधा आ जाएगा संकलन समय के भीतर)।

हालांकि यदि गतिशील एसक्यूएल पैरामीटर का उपयोग करता है या संकलन परिणामों की तुलना में दोहराना है तो See Caching Query Plans के अनुसार कैश किया जा सकता है जो संकलन समय को खत्म कर देगा। जानना दिलचस्प होगा कि कैश प्रविष्टियां कितनी देर तक लाइव, सत्र, सत्रों के बीच साझा की गईं आदि।