टी-एसक्यूएल प्रोग्रामर के सात घातक पाप

अच्छी तरह से पढ़ने योग्य कोड लिखना पर्याप्त नहीं है: इसे जल्दी से चलना चाहिए।

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

• डेटा स्टोरेज स्ट्रक्चर के आधार पर लिखें: यदि आप डेटा डेटाइम टाइप करते हैं, तो डेटटाइम का उपयोग करें, न कि वैरिका या किसी अन्य चीज का।
• इंडेक्स की उपलब्धता के आधार पर लिखें: यदि इंडेक्स टेबल पर बनाए गए हैं और वे वहां होने चाहिए, तो कोड लिखें ताकि यह इन इंडेक्स का पूरा फायदा उठा सके। सुनिश्चित करें कि केवल एक संकुल सूचकांक है, और प्रत्येक तालिका के लिए, इसका उपयोग सबसे कुशल तरीके से किया जाता है।
• क्वेरी ऑप्टिमाइज़र की सहायता के लिए लिखें: क्वेरी ऑप्टिमाइज़र DBMS का एक रोमांचक हिस्सा है। दुर्भाग्य से, आप एक क्वेरी लिखकर उसके काम को बहुत जटिल कर सकते हैं जो उसके लिए पार्स करने के लिए "मुश्किल" होगा, उदाहरण के लिए, नेस्टेड विचार युक्त - जब एक दृश्य दूसरे से डेटा प्राप्त करता है, और फिर एक तिहाई से - और इसी तरह। यह समझने के लिए अपना समय लें कि ऑप्टिमाइज़र कैसे काम करता है और इस तरह से प्रश्न लिखता है कि यह आपकी मदद कर सके, न कि आपको नुकसान पहुँचाए।

कुछ सामान्य गलतियाँ हैं जो लोग अपने टी-एसक्यूएल कोड में करते हैं - उन्हें नहीं बनाते हैं।

गलत डेटा प्रकारों का उपयोग करना

सिद्धांत रूप में, इस त्रुटि से बचना बहुत सरल है, लेकिन व्यवहार में यह काफी सामान्य है। उदाहरण के लिए, आप अपने डेटाबेस में कुछ प्रकार के डेटा का उपयोग कर रहे हैं। अपने मापदंडों और चर में इसका इस्तेमाल करें! हां, मुझे पता है कि SQL सर्वर एक डेटा प्रकार को दूसरे में डाल सकता है। लेकिन, जब एक अंतर्निहित प्रकार रूपांतरण होता है, या यदि आप स्वयं स्तंभ के डेटा प्रकार को दूसरे प्रकार में परिवर्तित करते हैं, तो आप संपूर्ण स्तंभ के लिए रूपांतरण करते हैं। जब आप WHERE क्लॉज या किसी सम्मिलित स्थिति में स्तंभ के लिए यह रूपांतरण करते हैं, तो आपको हमेशा एक टेबल स्कैन दिखाई देगा। इस स्तंभ पर एक उत्कृष्ट सूचकांक बनाया जा सकता है, लेकिन जब से आप तुलना करने के लिए इस कॉलम में संग्रहीत मानों के लिए CAST कर रहे हैं, उदाहरण के लिए, इस कॉलम में उस दिनांक के प्रकार के साथ संग्रहीत किया जाता है जब आपने शर्त में उपयोग किया था, तो इंडेक्स का उपयोग नहीं किया जाएगा।

विश्वास नहीं होता? आइए इस प्रश्न को देखें:

SELECT e.BusinessEntityID, e.NationalIDNumber FROM HumanResources.Employee AS e WHERE e.NationalIDNumber = 112457891; 

अच्छी तरह से लिखा है और बहुत सरल है। यह इस तालिका पर बनाए गए सूचकांक द्वारा कवर किया जाना चाहिए। लेकिन यहाँ निष्पादन योजना है:



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



यह सही है। यह एक चेतावनी (SQL Server 2012 में नया) है कि टाइपिंग रूपांतरण प्रगति पर है जो निष्पादन योजना को प्रभावित करता है। संक्षेप में, यह इसलिए है क्योंकि अनुरोध गलत डेटा प्रकार का उपयोग करता है:

 SELECT e.BusinessEntityID, e.NationalIDNumber FROM HumanResources.Employee AS e WHERE e.NationalIDNumber = '112457891'; 

और हमें निम्नलिखित क्वेरी निष्पादन योजना मिलती है:



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

सही डेटा प्रकारों का उपयोग करें।

शामिल होने की शर्तों की तैयारी में और जहां क्लॉस में कार्यों का उपयोग

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

 SELECT a.AddressLine1, a.AddressLine2, a.City, a.StateProvinceID FROM Person.Address AS a WHERE '4444' = LEFT(a.AddressLine1, 4) ; 

यह फ़ंक्शन, LEFT, एक तर्क के रूप में एक स्तंभ प्राप्त करता है, जो इस निष्पादन योजना में अनुवाद करता है:



नतीजतन, आपके द्वारा आवश्यक डेटा को खोजने के लिए 316 रीड ऑपरेशन किए जाते हैं, और इसमें 9 मिलीसेकंड लगते हैं (मेरे पास बहुत तेज डिस्क हैं)। ऐसा इसलिए है क्योंकि '4444' को इस फंक्शन द्वारा लौटी हर लाइन से तुलना करनी होगी। SQL सर्वर भी केवल एक टेबल को स्कैन नहीं कर सकता है, इसे प्रत्येक पंक्ति के लिए LEFT प्रदर्शन करने की आवश्यकता है। हालाँकि, आप ऐसा कुछ कर सकते हैं:

 SELECT a.AddressLine1, a.AddressLine2, a.City, a.StateProvinceID FROM Person.Address AS a WHERE a.AddressLine1 LIKE '4444%' ; 

और यहाँ हम एक पूरी तरह से अलग निष्पादन योजना देखते हैं:



एक क्वेरी में 3 रीड और 0 मिलीसेकंड की आवश्यकता होती है। वस्तुनिष्ठता के लिए, या इसे 1 मिलीसेकंड होने दें। यह एक विशाल प्रदर्शन को बढ़ावा देने वाला है। और सभी क्योंकि मैंने एक फ़ंक्शन का उपयोग किया था जिसे सूचकांक द्वारा खोज करने के लिए उपयोग किया जा सकता है (पहले इसे सरिअंट कहा जाता था - एक अचूक शब्द, सामान्य रूप से: SARG - खोज तर्क-यदि फ़ंक्शन SARGeable है - तो आप एक कॉलम पास कर सकते हैं तर्क और इंडेक्स सीक का उपयोग वैसे भी किया जाएगा, यदि SARGeable - alas, Index Scan का उपयोग हमेशा नहीं किया जाएगा - अनुवादक ।)। किसी भी स्थिति में, WHERE के भाव या खोज स्थितियों में फ़ंक्शंस का उपयोग न करें, या केवल उन्हीं का उपयोग करें जिन्हें इंडेक्स द्वारा खोज स्थितियों में उपयोग किया जा सकता है।

मल्टी स्टेटमेंट यूडीएफ का उपयोग करना

एमएसडीएन के रूसी संस्करण में बहु-कथन यूडीएफ मोटे तौर पर "उपयोगकर्ता-परिभाषित कार्यों में कई निर्देशों से मिलकर अनुवाद करता है, लेकिन यह मेरी राय में, किसी भी तरह से अजीब लगता है, इसलिए शीर्षक में और आगे पूरे पाठ में मैंने इस शब्द का अनुवाद करने से बचने की कोशिश की - लगभग । अनुवाद

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

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

एक उदाहरण काफी बड़ा है। यहाँ कुछ UDF हैं:

 CREATE FUNCTION dbo.SalesInfo () RETURNS @return_variable TABLE ( SalesOrderID INT, OrderDate DATETIME, SalesPersonID INT, PurchaseOrderNumber dbo.OrderNumber, AccountNumber dbo.AccountNumber, ShippingCity NVARCHAR(30) ) AS BEGIN; INSERT INTO @return_variable (SalesOrderID, OrderDate, SalesPersonID, PurchaseOrderNumber, AccountNumber, ShippingCity ) SELECT soh.SalesOrderID, soh.OrderDate, soh.SalesPersonID, soh.PurchaseOrderNumber, soh.AccountNumber, a.City FROM Sales.SalesOrderHeader AS soh JOIN Person.Address AS a ON soh.ShipToAddressID = a.AddressID ; RETURN ; END ; GO CREATE FUNCTION dbo.SalesDetails () RETURNS @return_variable TABLE ( SalesOrderID INT, SalesOrderDetailID INT, OrderQty SMALLINT, UnitPrice MONEY ) AS BEGIN; INSERT INTO @return_variable (SalesOrderID, SalesOrderDetailId, OrderQty, UnitPrice ) SELECT sod.SalesOrderID, sod.SalesOrderDetailID, sod.OrderQty, sod.UnitPrice FROM Sales.SalesOrderDetail AS sod ; RETURN ; END ; GO CREATE FUNCTION dbo.CombinedSalesInfo () RETURNS @return_variable TABLE ( SalesPersonID INT, ShippingCity NVARCHAR(30), OrderDate DATETIME, PurchaseOrderNumber dbo.OrderNumber, AccountNumber dbo.AccountNumber, OrderQty SMALLINT, UnitPrice MONEY ) AS BEGIN; INSERT INTO @return_variable (SalesPersonId, ShippingCity, OrderDate, PurchaseOrderNumber, AccountNumber, OrderQty, UnitPrice ) SELECT si.SalesPersonID, si.ShippingCity, si.OrderDate, si.PurchaseOrderNumber, si.AccountNumber, sd.OrderQty, sd.UnitPrice FROM dbo.SalesInfo() AS si JOIN dbo.SalesDetails() AS sd ON si.SalesOrderID = sd.SalesOrderID ; RETURN ; END ; GO 

महान संरचना। यह आपको बहुत सरल प्रश्न बनाने की अनुमति देता है। खैर, उदाहरण के लिए, यहाँ:

 SELECT csi.OrderDate, csi.PurchaseOrderNumber, csi.AccountNumber, csi.OrderQty, csi.UnitPrice FROM dbo.CombinedSalesInfo() AS csi WHERE csi.SalesPersonID = 277 AND csi.ShippingCity = 'Odessa' ; 

एक, बहुत ही सरल अनुरोध। यहाँ उनकी निष्पादन योजना है, जो बहुत सरल है:



यह केवल 2.17 सेकंड लेता है, 148 लाइनें लौटाता है और 1456 रीड ऑपरेशंस का उपयोग करता है। कृपया ध्यान दें कि हमारे फ़ंक्शन में शून्य लागत है और केवल एक टेबल, टेबल चर को स्कैन करने से अनुरोध की लागत प्रभावित होती है। हम्म, क्या यह सच है? आइए यह देखने की कोशिश करें कि शून्य-लागत वाले यूडीएफ निष्पादन विवरण के पीछे क्या है। इस अनुरोध को कैश से फ़ंक्शन निष्पादन योजना मिलेगी:

 SELECT deqp.query_plan, dest.text, SUBSTRING(dest.text, (deqs.statement_start_offset / 2) + 1, (deqs.statement_end_offset - deqs.statement_start_offset) / 2 + 1) AS actualstatement FROM sys.dm_exec_query_stats AS deqs CROSS APPLY sys.dm_exec_query_plan(deqs.plan_handle) AS deqp CROSS APPLY sys.dm_exec_sql_text(deqs.sql_handle) AS dest WHERE deqp.objectid = OBJECT_ID('dbo.CombinedSalesInfo'); 

और यहाँ वास्तव में क्या होता है:



वाह, यह इन छोटे कार्यों के कुछ और जैसा दिखता है और तालिकाओं के स्कैन यहां छिपे हुए हैं, जो लगभग, लेकिन अभी भी काफी नहीं है, कुछ भी नहीं। साथ ही, हैश मैच ऑपरेटर से जुड़ता है, जो टेम्पपेड को लिखता है और निष्पादन पर काफी खर्च होता है। आइए, UDF के किसी अन्य के लिए निष्पादन योजना देखें:



यहाँ! और अब हम क्लस्टर्ड इंडेक्स स्कैन देखते हैं, जिसमें बड़ी संख्या में पंक्तियों को स्कैन किया जाता है। यह अब महान नहीं है। सामान्य तौर पर, इस पूरी स्थिति में, यूडीएफ कम और कम आकर्षक लगते हैं। क्या होगा अगर हम, ठीक है, मुझे सीधे पता नहीं है, बस सीधे तालिकाओं तक पहुंचने का प्रयास करें। इस तरह, उदाहरण के लिए:

 SELECT soh.OrderDate, soh.PurchaseOrderNumber, soh.AccountNumber, sod.OrderQty, sod.UnitPrice FROM Sales.SalesOrderHeader AS soh JOIN Sales.SalesOrderDetail AS sod ON soh.SalesOrderID = sod.SalesOrderID JOIN Person.Address AS ba ON soh.BillToAddressID = ba.AddressID JOIN Person.Address AS sa ON soh.ShipToAddressID = sa.AddressID WHERE soh.SalesPersonID = 277 AND sa.City = 'Odessa' ; 

अब, इस क्वेरी को पूरा करने के बाद, हम ठीक उसी डेटा को प्राप्त करेंगे, लेकिन केवल 310 मिलीसेकंड में, 2170 में नहीं। इसके अलावा, SQL सर्वर सिर्फ 911 रीड्स का प्रदर्शन करेगा, 1456 का नहीं। ईमानदारी से, प्रदर्शन का उपयोग करना बहुत आसान है। यूडीएफ

"तेजी से भागो!" सक्षम करना: डर्टी रीडिंग का उपयोग करना

अतीत में लौटते हुए, बोर्ड पर 286 प्रोसेसर वाले पुराने कंप्यूटरों पर, हम याद कर सकते हैं कि कई कारणों से, उनके सामने पैनल पर टर्बो बटन था। यदि आप गलती से इसे "निचोड़" लेते हैं, तो कंप्यूटर तुरंत पागलपन को धीमा करना शुरू कर देता है। इस प्रकार, आपने महसूस किया कि अधिकतम बैंडविड्थ सुनिश्चित करने के लिए कुछ चीजों को हमेशा चालू रखना चाहिए। इसी तरह, कई लोग SQL सर्वर के लिए एक टर्बो बटन के रूप में अलगाव स्तर READ_UNCOMMITTED और NO_LOCK संकेत को देखते हैं। उनका उपयोग करते समय, सुनिश्चित करें - लगभग किसी भी अनुरोध और एक पूरे के रूप में पूरी प्रणाली तेज हो जाएगी। यह इस तथ्य के कारण है कि पढ़ने के दौरान कोई ताले नहीं लगाए जाएंगे और जांच की जाएगी। कम ताले - तेज परिणाम। लेकिन ...

जब आप अपने प्रश्नों में READ_UNCOMMITTED या NO_LOCK का उपयोग करते हैं, तो आप गंदे पढ़ते हैं। हर कोई समझता है कि इसका मतलब है कि आप "कुत्ता" पढ़ सकते हैं और "बिल्ली" नहीं अगर उस पल में अपडेट ऑपरेशन अभी तक पूरा नहीं हुआ है। लेकिन, इसके अलावा, आप वास्तव में, साथ ही डुप्लिकेट पंक्तियों की तुलना में अधिक या कम पंक्तियां प्राप्त कर सकते हैं, क्योंकि डेटा पृष्ठ आपके अनुरोध के निष्पादन के दौरान आगे बढ़ सकते हैं, और आप इससे बचने के लिए कोई ताले नहीं लगाते हैं। मुझे आपके बारे में पता नहीं है, लेकिन मैंने जिन कंपनियों के लिए काम किया है, उनमें से अधिकांश को उम्मीद थी कि अधिकांश प्रणालियों के अधिकांश प्रश्न पूरा डेटा वापस कर देंगे। समान मापदंडों के साथ समान क्वेरी, समान डेटा सेट पर निष्पादित, समान परिणाम देना चाहिए। यदि आप NO_LOCK का उपयोग नहीं करते हैं। इसे सत्यापित करने के लिए, मैं आपको इस पोस्ट को पढ़ने की सलाह देता हूं।

अनुरोधों में संकेत का अनुचित उपयोग

लोग संकेत का उपयोग करने के बारे में बहुत जल्दबाजी में निर्णय लेते हैं। सबसे आम स्थिति तब होती है जब एक अनुरोध पर संकेत एक, बहुत दुर्लभ समस्या को हल करने में मदद करता है। लेकिन, जब लोग इस अनुरोध पर एक महत्वपूर्ण प्रदर्शन को बढ़ावा देते हैं ... वे तुरंत इसे हर जगह सामान्य रूप से पॉप करना शुरू करते हैं।

उदाहरण के लिए, बहुत से लोग सोचते हैं कि टेबल से जुड़ने के लिए LOOP JOIN सबसे अच्छा तरीका है। वे इस निष्कर्ष पर आते हैं, क्योंकि यह अक्सर छोटे और त्वरित प्रश्नों में पाया जाता है। इसलिए, वे LOOP JOIN का उपयोग करने के लिए SQL सर्वर को बाध्य करने का निर्णय लेते हैं। यह बिल्कुल जटिल नहीं है:

 SELECT s.[Name] AS StoreName, p.LastName + ', ' + p.FirstName FROM Sales.Store AS s JOIN sales.SalesPerson AS sp ON s.SalesPersonID = sp.BusinessEntityID JOIN HumanResources.Employee AS e ON sp.BusinessEntityID = e.BusinessEntityID JOIN Person.Person AS p ON e.BusinessEntityID = p.BusinessEntityID OPTION (LOOP JOIN); 

इस अनुरोध को 101 मिलीसेकंड निष्पादित किया जाता है और 4115 रीड ऑपरेशन करता है। सामान्य तौर पर, बुरा नहीं है, लेकिन अगर हम इस संकेत को हटाते हैं, तो वही अनुरोध 90 मिलीसेकंड में निष्पादित किया जाएगा और केवल 2370 रीडिंग का उत्पादन करेगा। सिस्टम को जितना अधिक लोड किया जाएगा, एक संकेत का उपयोग किए बिना अनुरोध की प्रभावशीलता उतनी ही स्पष्ट होगी।

यहाँ एक और उदाहरण है। लोग अक्सर एक टेबल पर एक इंडेक्स बनाते हैं, जिससे यह समस्या का समाधान होता है। इसलिए, हमारा अनुरोध है:

 SELECT * FROM Purchasing.PurchaseOrderHeader AS poh WHERE poh.PurchaseOrderID * 2 = 3400; 

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

 SELECT * FROM Purchasing.PurchaseOrderHeader AS poh WITH (INDEX (PK_PurchaseOrderHeader_PurchaseOrderID)) WHERE poh.PurchaseOrderID * 2 = 3400; 

और अब उन्हें अनुक्रमणिका का एक स्कैन प्राप्त होता है, बजाय क्लस्टर किए हुए एक के, इसलिए सूचकांक "उपयोग" है, है ना? लेकिन क्वेरी प्रदर्शन बदल रहा है - अब 11 रीड ऑपरेशंस के बजाय, 44 निष्पादित किए गए हैं (दोनों में लगभग 0 मिलीसेकंड निष्पादन समय है, क्योंकि मेरे पास वास्तव में तेज डिस्क हैं)। "उपयोग किया जाता है," इसका उपयोग किया जाता है, लेकिन जैसा कि इरादा नहीं है। इस समस्या का समाधान इस तरह से अनुरोध को फिर से लिखना है:

 SELECT * FROM Purchasing.PurchaseOrderHeader poh WHERE PurchaseOrderID = 3400 / 2; 

अब रीड ऑपरेशंस की संख्या घटकर दो हो गई है, क्योंकि इंडेक्स सर्च का इस्तेमाल किया जाता है - इंडेक्स का सही इस्तेमाल होता है।

प्रश्नों में संकेत हमेशा अंतिम रूप से लागू किए जाने चाहिए, क्योंकि अन्य सभी संभावित विकल्पों का परीक्षण किया गया है और सकारात्मक परिणाम नहीं मिला है।

क्वेरी निष्पादन परिणाम के पंक्ति-दर-पंक्ति प्रसंस्करण का उपयोग करना ('पंक्ति द्वारा पंक्तिबद्ध करना' प्रसंस्करण)

पंक्ति-वार प्रसंस्करण को सेट पर संचालन के बजाय WHILE-चक्र में कर्सर या संचालन का उपयोग करके किया जाता है। जब उपयोग किया जाता है, तो प्रदर्शन बहुत कम होता है। आमतौर पर दो कारणों से कर्सर का उपयोग किया जाता है। पहला एक डेवलपर्स है जो अपने कोड में लाइन-बाय-लाइन प्रोसेसिंग का उपयोग करने के लिए उपयोग किया जाता है, और दूसरा डेवलपर्स है जो ओरेकल से आया है, जो सोचते हैं कि कर्सर एक अच्छी बात है। कारण जो भी हो, कर्सर कली में उत्पादकता को मारते हैं।

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

 BEGIN TRANSACTION DECLARE @Name NVARCHAR(50) , @Color NVARCHAR(15) , @Weight DECIMAL(8, 2) DECLARE BigUpdate CURSOR FOR SELECT p.[Name] ,p.Color ,p.[Weight] FROM Production.Product AS p ; OPEN BigUpdate ; FETCH NEXT FROM BigUpdate INTO @Name, @Color, @Weight ; WHILE @@FETCH_STATUS = 0 BEGIN IF @Weight < 3 BEGIN UPDATE Production.Product SET Color = 'Blue' WHERE CURRENT OF BigUpdate END FETCH NEXT FROM BigUpdate INTO @Name, @Color, @Weight ; END CLOSE BigUpdate ; DEALLOCATE BigUpdate ; SELECT * FROM Production.Product AS p WHERE Color = 'Blue' ; ROLLBACK TRANSACTION 

प्रत्येक पुनरावृत्ति में, हम दो रीड ऑपरेशन करते हैं, और हमारे मानदंडों को पूरा करने वाले उत्पादों की संख्या सैकड़ों है। मेरी मशीन पर, कोई भार नहीं, रनटाइम एक सेकंड से अधिक है। यह पूरी तरह से अस्वीकार्य है, खासकर जब से इस अनुरोध को फिर से लिखना बहुत सरल है:

 BEGIN TRANSACTION UPDATE Production.Product SET Color = 'BLUE' WHERE [Weight] < 3 ; ROLLBACK TRANSACTION 

अब केवल 15 रीड ऑपरेशन किए जाते हैं और निष्पादन का समय केवल 1 मिलीसेकंड है। हंसो मत। लोग अक्सर ऐसे कोड लिखते हैं, और इससे भी बदतर। कर्सर एक ऐसी चीज है, जिससे बचा जाना चाहिए और केवल उसी का उपयोग किया जाना चाहिए जहां आप उनके बिना नहीं कर सकते हैं - उदाहरण के लिए, रखरखाव कार्यों में, जहां आपको अलग-अलग तालिकाओं या डेटाबेस से "रन" करने की आवश्यकता होती है।

नेस्टेड विचारों का अनुचित उपयोग

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

उदाहरण के लिए, विचारों को परिभाषित करने वाले सरल प्रश्नों का एक क्रम है:

 CREATE VIEW dbo.SalesInfoView AS SELECT soh.SalesOrderID, soh.OrderDate, soh.SalesPersonID, soh.PurchaseOrderNumber, soh.AccountNumber, a.City AS ShippingCity FROM Sales.SalesOrderHeader AS soh JOIN Person.Address AS a ON soh.ShipToAddressID = a.AddressID ; CREATE VIEW dbo.SalesDetailsView AS SELECT sod.SalesOrderID, sod.SalesOrderDetailID, sod.OrderQty, sod.UnitPrice FROM Sales.SalesOrderDetail AS sod ; CREATE VIEW dbo.CombinedSalesInfoView AS SELECT si.SalesPersonID, si.ShippingCity, si.OrderDate, si.PurchaseOrderNumber, si.AccountNumber, sd.OrderQty, sd.UnitPrice FROM dbo.SalesInfoView AS si JOIN dbo.SalesDetailsView AS sd ON si.SalesOrderID = sd.SalesOrderID ; 

और यहां पाठ का लेखक अनुरोध को इंगित करना भूल गया, लेकिन वह इसे टिप्पणियों में देता है (अनुवादक का नोट):

 SELECT csi.OrderDate FROM dbo. CominedSalesInfoView csi WHERE csi.SalesPersonID = 277 

परिणामस्वरूप, हमारे अनुरोध को 155 मिलीसेकंड निष्पादित किया जाता है और 965 रीड ऑपरेशंस का उपयोग करता है। यहाँ उसकी निष्पादन योजना है:



यह अच्छा लग रहा है, खासकर जब से हमें 7000 लाइनें मिलती हैं, इसलिए सब कुछ क्रम में लगता है। लेकिन क्या होगा अगर हम इस तरह के अनुरोध को निष्पादित करने की कोशिश करते हैं:

 SELECT soh.OrderDate FROM Sales.SalesOrderHeader AS soh WHERE soh.SalesPersonID = 277 ; 

और अब अनुरोध 3 मिलीसेकंड में पूरा हो गया है और 685 रीड ऑपरेशन का उपयोग करता है - यह काफी अलग है। और यहाँ उसकी निष्पादन योजना है:



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

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