🥇C#.NET में LINQ क्वेरीज़ को अनुकूलित करने के तरीके

परिचय

В यह लेख कुछ अनुकूलन विधियों पर विचार किया गया LINQ प्रश्न.
यहां हम कोड अनुकूलन से संबंधित कुछ और दृष्टिकोण भी प्रस्तुत करते हैं LINQ प्रश्न.

ह ज्ञात है कि LINQ(भाषा-एकीकृत क्वेरी) डेटा स्रोत से पूछताछ के लिए एक सरल और सुविधाजनक भाषा है।

А LINQ से SQL DBMS में डेटा तक पहुँचने की एक तकनीक है। यह डेटा के साथ काम करने के लिए एक शक्तिशाली उपकरण है, जहां प्रश्नों का निर्माण एक घोषणात्मक भाषा के माध्यम से किया जाता है, जिसे बाद में परिवर्तित किया जाएगा एसक्यूएल प्रश्न प्लेटफ़ॉर्म और निष्पादन के लिए डेटाबेस सर्वर को भेजा गया। हमारे मामले में, DBMS से हमारा तात्पर्य है एमएस SQL सर्वर.

हालांकि, LINQ प्रश्न सर्वोत्तम ढंग से लिखे गए शब्दों में परिवर्तित नहीं किए गए हैं एसक्यूएल प्रश्न, जिसे एक अनुभवी डीबीए अनुकूलन की सभी बारीकियों के साथ लिख सकता है एसक्यूएल प्रश्न:

इष्टतम कनेक्शन (शामिल हों) और परिणामों को फ़िल्टर करना (कहां)
कनेक्शन और समूह स्थितियों का उपयोग करने में कई बारीकियाँ
प्रतिस्थापन स्थितियों में कई भिन्नताएँ IN पर मौजूद हैи अंदर नही, <> चालू मौजूद है
अस्थायी तालिकाओं, सीटीई, तालिका चर के माध्यम से परिणामों की मध्यवर्ती कैशिंग
वाक्य का प्रयोग (विकल्प) निर्देशों और तालिका संकेतों के साथ साथ में (...)
चयन के दौरान अनावश्यक डेटा रीडिंग से छुटकारा पाने के एक साधन के रूप में अनुक्रमित दृश्यों का उपयोग करना

परिणामी मुख्य प्रदर्शन बाधाएँ एसक्यूएल प्रश्न संकलन करते समय LINQ प्रश्न हैं:

एक अनुरोध में संपूर्ण डेटा चयन तंत्र का समेकन
कोड के समान ब्लॉकों की नकल करना, जो अंततः कई अनावश्यक डेटा रीड्स की ओर ले जाता है
बहु-घटक स्थितियों के समूह (तार्किक "और" और "या") - और и OR, जटिल परिस्थितियों में संयोजन, इस तथ्य की ओर ले जाता है कि ऑप्टिमाइज़र, आवश्यक क्षेत्रों के लिए उपयुक्त गैर-क्लस्टर इंडेक्स वाले, अंततः क्लस्टर्ड इंडेक्स के खिलाफ स्कैन करना शुरू कर देता है (सूचकांक स्कैन) स्थितियों के समूहों द्वारा
सबक्वेरीज़ की डीप नेस्टिंग पार्सिंग को बहुत समस्याग्रस्त बना देती है एसक्यूएल कथन और डेवलपर्स की ओर से क्वेरी योजना का विश्लेषण और डीबीए

अनुकूलन के तरीके

अब सीधे अनुकूलन विधियों पर चलते हैं।

1) अतिरिक्त अनुक्रमण

मुख्य चयन तालिकाओं पर फ़िल्टर पर विचार करना सबसे अच्छा है, क्योंकि अक्सर पूरी क्वेरी एक या दो मुख्य तालिकाओं (एप्लिकेशन-लोग-संचालन) के आसपास और शर्तों के एक मानक सेट (IsClosed, Canceled, Enabled, status) के साथ बनाई जाती है। पहचाने गए नमूनों के लिए उचित सूचकांक बनाना महत्वपूर्ण है।

यह समाधान तब समझ में आता है जब इन फ़ील्ड्स का चयन क्वेरी में लौटाए गए सेट को महत्वपूर्ण रूप से सीमित कर देता है।

उदाहरण के लिए, हमारे पास 500000 एप्लिकेशन हैं। हालाँकि, केवल 2000 सक्रिय एप्लिकेशन हैं। तब एक सही ढंग से चयनित सूचकांक हमें बचाएगा सूचकांक स्कैन एक बड़ी मेज पर और आपको गैर-संकुल सूचकांक के माध्यम से शीघ्रता से डेटा का चयन करने की अनुमति देगा।

साथ ही, इंडेक्स की कमी को क्वेरी योजनाओं को पार्स करने या सिस्टम दृश्य आंकड़े एकत्र करने के संकेतों के माध्यम से पहचाना जा सकता है एमएस SQL सर्वर:

स्थानिक अनुक्रमणिका को छोड़कर, सभी दृश्य डेटा में लुप्त अनुक्रमणिका के बारे में जानकारी होती है।

हालाँकि, इंडेक्स और कैशिंग अक्सर खराब लिखे गए परिणामों से निपटने के तरीके हैं LINQ प्रश्न и एसक्यूएल प्रश्न.

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

यह आंशिक रूप से उचित है, क्योंकि उपयोगकर्ता को हमेशा नवीनतम डेटा की आवश्यकता नहीं होती है और उपयोगकर्ता इंटरफ़ेस की प्रतिक्रिया का स्वीकार्य स्तर होता है।

यह दृष्टिकोण व्यावसायिक आवश्यकताओं को हल करने की अनुमति देता है, लेकिन अंततः समस्याओं के समाधान में देरी करके सूचना प्रणाली के प्रदर्शन को कम कर देता है।

यह भी याद रखने योग्य है कि खोज की प्रक्रिया में आवश्यक अनुक्रमणिकाएँ जोड़ने के लिए सुझाव दिए जाते हैं MS SQL अनुकूलन गलत हो सकता है, जिसमें निम्न स्थितियाँ शामिल हैं:

यदि फ़ील्ड के समान सेट वाले इंडेक्स पहले से मौजूद हैं
यदि तालिका में फ़ील्ड को अनुक्रमण प्रतिबंधों के कारण अनुक्रमित नहीं किया जा सकता है (अधिक विस्तार से वर्णित है)। यहां).

2) विशेषताओं को एक नई विशेषता में विलय करना

कभी-कभी एक तालिका से कुछ फ़ील्ड, जो स्थितियों के समूह के लिए आधार के रूप में कार्य करती हैं, को एक नए फ़ील्ड को शुरू करके प्रतिस्थापित किया जा सकता है।

यह स्थिति फ़ील्ड के लिए विशेष रूप से सच है, जो आमतौर पर या तो बिट या पूर्णांक प्रकार के होते हैं।

उदाहरण:

बंद है = 0 और रद्द किया गया = 0 और सक्षम = 0 द्वारा प्रतिस्थापित किया जाता है स्थिति = 1.

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

यह प्रदर्शन समस्या का मौलिक समाधान है, क्योंकि हम अनावश्यक गणनाओं के बिना डेटा तक पहुंचते हैं।

3) दृश्य का भौतिकीकरण

दुर्भाग्य से, में LINQ प्रश्न अस्थायी तालिकाओं, सीटीई और तालिका चर का सीधे उपयोग नहीं किया जा सकता है।

हालाँकि, इस मामले के लिए अनुकूलन करने का एक और तरीका है - अनुक्रमित दृश्य।

स्थिति समूह (उपरोक्त उदाहरण से) बंद है = 0 और रद्द किया गया = 0 और सक्षम = 0 (या अन्य समान स्थितियों का एक सेट) एक बड़े सेट से डेटा के एक छोटे टुकड़े को कैश करते हुए, अनुक्रमित दृश्य में उनका उपयोग करने का एक अच्छा विकल्प बन जाता है।

लेकिन किसी दृष्टिकोण को मूर्त रूप देते समय कई प्रतिबंध होते हैं:

उपप्रश्नों, उपवाक्यों का उपयोग मौजूद है का उपयोग करके प्रतिस्थापित किया जाना चाहिए शामिल हों
आप वाक्यों का उपयोग नहीं कर सकते संघ, यूनिअन ऑल, अपवाद, एक दूसरे को काटना
आप तालिका संकेत और खंड का उपयोग नहीं कर सकते विकल्प
साइकिल के साथ काम करने की कोई संभावना नहीं
विभिन्न तालिकाओं से डेटा को एक दृश्य में प्रदर्शित करना असंभव है

यह याद रखना महत्वपूर्ण है कि अनुक्रमित दृश्य का उपयोग करने का वास्तविक लाभ केवल इसे वास्तव में अनुक्रमित करके ही प्राप्त किया जा सकता है।

लेकिन किसी दृश्य को कॉल करते समय, इन अनुक्रमणिकाओं का उपयोग नहीं किया जा सकता है, और उन्हें स्पष्ट रूप से उपयोग करने के लिए, आपको निर्दिष्ट करना होगा साथ(NOEXPAND).

चूंकि LINQ प्रश्न तालिका संकेतों को परिभाषित करना असंभव है, इसलिए आपको एक और प्रतिनिधित्व बनाना होगा - निम्नलिखित रूप का एक "रैपर":

CREATE VIEW ИМЯ_представления AS SELECT * FROM MAT_VIEW WITH (NOEXPAND);

4) टेबल फ़ंक्शंस का उपयोग करना

अक्सर में LINQ प्रश्न सबक्वेरीज़ के बड़े ब्लॉक या जटिल संरचना वाले दृश्यों का उपयोग करने वाले ब्लॉक एक बहुत ही जटिल और उप-इष्टतम निष्पादन संरचना के साथ एक अंतिम क्वेरी बनाते हैं।

टेबल फ़ंक्शंस का उपयोग करने के मुख्य लाभ LINQ प्रश्न:

दृश्य के मामले में, किसी ऑब्जेक्ट के रूप में उपयोग और निर्दिष्ट करने की क्षमता, लेकिन आप इनपुट पैरामीटर का एक सेट पास कर सकते हैं:
फ़ंक्शन से (@param1, @param2 ...)
परिणामस्वरूप, लचीला डेटा नमूनाकरण प्राप्त किया जा सकता है
तालिका फ़ंक्शन का उपयोग करने के मामले में, ऊपर वर्णित अनुक्रमित दृश्यों के मामले में ऐसे कोई मजबूत प्रतिबंध नहीं हैं:
1. तालिका संकेत:
  के माध्यम से LINQ आप निर्दिष्ट नहीं कर सकते कि कौन से इंडेक्स का उपयोग किया जाना चाहिए और क्वेरी करते समय डेटा अलगाव स्तर निर्धारित नहीं किया जा सकता है।
  लेकिन फ़ंक्शन में ये क्षमताएं हैं।
  फ़ंक्शन के साथ, आप एक काफी स्थिर निष्पादन क्वेरी योजना प्राप्त कर सकते हैं, जहां इंडेक्स और डेटा अलगाव स्तरों के साथ काम करने के नियम परिभाषित किए गए हैं
2. फ़ंक्शन का उपयोग अनुक्रमित दृश्यों की तुलना में, प्राप्त करने की अनुमति देता है:
  - जटिल डेटा नमूनाकरण तर्क (लूप का उपयोग करके भी)
  - कई अलग-अलग तालिकाओं से डेटा लाया जा रहा है
  - के उपयोग संघ и मौजूद है
प्रस्ताव विकल्प जब हमें समवर्ती नियंत्रण प्रदान करने की आवश्यकता होती है तो यह बहुत उपयोगी होता है विकल्प(मैक्सडॉप एन), क्वेरी निष्पादन योजना का क्रम। उदाहरण के लिए:
- आप क्वेरी योजना का जबरन पुनः निर्माण निर्दिष्ट कर सकते हैं विकल्प (पुनःसंकलन)
- आप यह निर्दिष्ट कर सकते हैं कि क्वेरी योजना को क्वेरी में निर्दिष्ट जॉइन ऑर्डर का उपयोग करने के लिए बाध्य किया जाए या नहीं विकल्प (बल आदेश)
के बारे में अधिक जानकारी विकल्प वर्णित यहां.
सबसे संकीर्ण और सबसे आवश्यक डेटा स्लाइस का उपयोग करना:
बड़े डेटा सेट को कैश में संग्रहीत करने की कोई आवश्यकता नहीं है (जैसा कि अनुक्रमित दृश्यों के मामले में है), जहां से आपको अभी भी डेटा को पैरामीटर द्वारा फ़िल्टर करने की आवश्यकता है।
उदाहरण के लिए, एक तालिका है जिसका फ़िल्टर कहां तीन फ़ील्ड का उपयोग किया जाता है (ए, बी, सी).

परंपरागत रूप से, सभी अनुरोधों की एक स्थिर स्थिति होती है ए = 0 और बी = 0.

हालाँकि, फ़ील्ड के लिए अनुरोध c अधिक परिवर्तनशील.

चलो शर्त ए = 0 और बी = 0 यह वास्तव में हमें आवश्यक परिणामी सेट को हजारों रिकॉर्ड तक सीमित करने में मदद करता है, लेकिन शर्त चालू है с चयन को सौ रिकॉर्ड तक सीमित कर देता है।

यहां टेबल फ़ंक्शन एक बेहतर विकल्प हो सकता है।

साथ ही, एक तालिका फ़ंक्शन निष्पादन समय में अधिक पूर्वानुमानित और सुसंगत होता है।

उदाहरण

आइए उदाहरण के तौर पर प्रश्न डेटाबेस का उपयोग करके एक उदाहरण कार्यान्वयन देखें।

एक निवेदन है चुनते हैं, जो कई तालिकाओं को जोड़ता है और एक दृश्य (ऑपरेटिवक्वेश्चन) का उपयोग करता है, जिसमें संबद्धता की जांच ईमेल द्वारा की जाती है (के माध्यम से) मौजूद है) से "सक्रिय क्वेरीज़" ([ऑपरेटिव प्रश्न]):

अनुरोध क्रमांक 1

(@p__linq__0 nvarchar(4000))SELECT
1 AS [C1],
[Extent1].[Id] AS [Id],
[Join2].[Object_Id] AS [Object_Id],
[Join2].[ObjectType_Id] AS [ObjectType_Id],
[Join2].[Name] AS [Name],
[Join2].[ExternalId] AS [ExternalId]
FROM [dbo].[Questions] AS [Extent1]
INNER JOIN (SELECT [Extent2].[Object_Id] AS [Object_Id],
[Extent2].[Question_Id] AS [Question_Id], [Extent3].[ExternalId] AS [ExternalId],
[Extent3].[ObjectType_Id] AS [ObjectType_Id], [Extent4].[Name] AS [Name]
FROM [dbo].[ObjectQuestions] AS [Extent2]
INNER JOIN [dbo].[Objects] AS [Extent3] ON [Extent2].[Object_Id] = [Extent3].[Id]
LEFT OUTER JOIN [dbo].[ObjectTypes] AS [Extent4] 
ON [Extent3].[ObjectType_Id] = [Extent4].[Id] ) AS [Join2] 
ON [Extent1].[Id] = [Join2].[Question_Id]
WHERE ([Extent1].[AnswerId] IS NULL) AND (0 = [Extent1].[Exp]) AND ( EXISTS (SELECT
1 AS [C1]
FROM [dbo].[OperativeQuestions] AS [Extent5]
WHERE (([Extent5].[Email] = @p__linq__0) OR (([Extent5].[Email] IS NULL) 
AND (@p__linq__0 IS NULL))) AND ([Extent5].[Id] = [Extent1].[Id])
));

दृश्य की संरचना काफी जटिल है: इसमें सबक्वेरी जुड़ती है और सॉर्टिंग का उपयोग करती है DISTINCT, जो सामान्य तौर पर काफी संसाधन-गहन ऑपरेशन है।

ऑपरेटिवक्वेश्चन का एक नमूना लगभग दस हजार रिकॉर्ड का है।

इस क्वेरी के साथ मुख्य समस्या यह है कि बाहरी क्वेरी के रिकॉर्ड के लिए, एक आंतरिक सबक्वेरी को [ऑपरेटिवक्वेश्चन] दृश्य पर निष्पादित किया जाता है, जो हमें [ईमेल] = @p__linq__0 के लिए आउटपुट चयन को सीमित करने की अनुमति देता है (के माध्यम से) मौजूद है) सैकड़ों रिकॉर्ड तक।

और ऐसा लग सकता है कि सबक्वेरी को एक बार [ईमेल] = @p__linq__0 द्वारा रिकॉर्ड्स की गणना करनी चाहिए, और फिर इन सौ रिकॉर्ड्स को प्रश्नों के साथ आईडी द्वारा जोड़ा जाना चाहिए, और क्वेरी तेज़ होगी।

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

वास्तव में, अनुरोध सभी हजारों ऑपरेटिवक्वेश्चन रिकॉर्ड के साथ काम करता है, लेकिन ईमेल के माध्यम से केवल रुचि के डेटा की आवश्यकता होती है।

ऑपरेटिव प्रश्न पाठ देखें:

अनुरोध क्रमांक 2

 
CREATE VIEW [dbo].[OperativeQuestions]
AS
SELECT DISTINCT Q.Id, USR.email AS Email
FROM            [dbo].Questions AS Q INNER JOIN
                         [dbo].ProcessUserAccesses AS BPU ON BPU.ProcessId = CQ.Process_Id 
OUTER APPLY
                     (SELECT   1 AS HasNoObjects
                      WHERE   NOT EXISTS
                                    (SELECT   1
                                     FROM     [dbo].ObjectUserAccesses AS BOU
                                     WHERE   BOU.ProcessUserAccessId = BPU.[Id] AND BOU.[To] IS NULL)
) AS BO INNER JOIN
                         [dbo].Users AS USR ON USR.Id = BPU.UserId
WHERE        CQ.[Exp] = 0 AND CQ.AnswerId IS NULL AND BPU.[To] IS NULL 
AND (BO.HasNoObjects = 1 OR
              EXISTS (SELECT   1
                           FROM   [dbo].ObjectUserAccesses AS BOU INNER JOIN
                                      [dbo].ObjectQuestions AS QBO 
                                                  ON QBO.[Object_Id] =BOU.ObjectId
                               WHERE  BOU.ProcessUserAccessId = BPU.Id 
                               AND BOU.[To] IS NULL AND QBO.Question_Id = CQ.Id));

DbContext में आरंभिक दृश्य मैपिंग (EF Core 2)

public class QuestionsDbContext : DbContext
{
    //...
    public DbQuery<OperativeQuestion> OperativeQuestions { get; set; }
    //...
    protected override void OnModelCreating(ModelBuilder modelBuilder)
    {
        modelBuilder.Query<OperativeQuestion>().ToView("OperativeQuestions");
    }
}

प्रारंभिक LINQ क्वेरी

var businessObjectsData = await context
    .OperativeQuestions
    .Where(x => x.Email == Email)
    .Include(x => x.Question)
    .Select(x => x.Question)
    .SelectMany(x => x.ObjectQuestions,
                (x, bo) => new
                {
                    Id = x.Id,
                    ObjectId = bo.Object.Id,
                    ObjectTypeId = bo.Object.ObjectType.Id,
                    ObjectTypeName = bo.Object.ObjectType.Name,
                    ObjectExternalId = bo.Object.ExternalId
                })
    .ToListAsync();

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

हालाँकि यह एक अच्छा समाधान है, इस समस्या को अनुकूलित करने का एक और विकल्प है।

मुख्य उद्देश्य ऑपरेटिवक्वेश्चन दृश्य से [ईमेल] = @p__linq__0 द्वारा प्रविष्टियों को कैश करना है।

डेटाबेस में तालिका फ़ंक्शन [dbo].[OperativeQuestionsUserMail] का परिचय दें।

ईमेल को इनपुट पैरामीटर के रूप में भेजकर, हमें मानों की एक तालिका वापस मिलती है:

अनुरोध क्रमांक 3


CREATE FUNCTION [dbo].[OperativeQuestionsUserMail]
(
    @Email  nvarchar(4000)
)
RETURNS
@tbl TABLE
(
    [Id]           uniqueidentifier,
    [Email]      nvarchar(4000)
)
AS
BEGIN
        INSERT INTO @tbl ([Id], [Email])
        SELECT Id, @Email
        FROM [OperativeQuestions]  AS [x] WHERE [x].[Email] = @Email;
     
    RETURN;
END

यह पूर्वनिर्धारित डेटा संरचना के साथ मानों की एक तालिका लौटाता है।

ऑपरेटिवक्वेस्टियंसयूजरमेल की क्वेरीज़ को इष्टतम बनाने और इष्टतम क्वेरी योजनाओं के लिए, एक सख्त संरचना की आवश्यकता होती है, न कि तालिका को रिटर्न के रूप में लौटाता है...

इस स्थिति में, आवश्यक क्वेरी 1 को क्वेरी 4 में बदल दिया जाता है:

अनुरोध क्रमांक 4

(@p__linq__0 nvarchar(4000))SELECT
1 AS [C1],
[Extent1].[Id] AS [Id],
[Join2].[Object_Id] AS [Object_Id],
[Join2].[ObjectType_Id] AS [ObjectType_Id],
[Join2].[Name] AS [Name],
[Join2].[ExternalId] AS [ExternalId]
FROM (
    SELECT Id, Email FROM [dbo].[OperativeQuestionsUserMail] (@p__linq__0)
) AS [Extent0]
INNER JOIN [dbo].[Questions] AS [Extent1] ON([Extent0].Id=[Extent1].Id)
INNER JOIN (SELECT [Extent2].[Object_Id] AS [Object_Id], [Extent2].[Question_Id] AS [Question_Id], [Extent3].[ExternalId] AS [ExternalId], [Extent3].[ObjectType_Id] AS [ObjectType_Id], [Extent4].[Name] AS [Name]
FROM [dbo].[ObjectQuestions] AS [Extent2]
INNER JOIN [dbo].[Objects] AS [Extent3] ON [Extent2].[Object_Id] = [Extent3].[Id]
LEFT OUTER JOIN [dbo].[ObjectTypes] AS [Extent4] 
ON [Extent3].[ObjectType_Id] = [Extent4].[Id] ) AS [Join2] 
ON [Extent1].[Id] = [Join2].[Question_Id]
WHERE ([Extent1].[AnswerId] IS NULL) AND (0 = [Extent1].[Exp]);

DbContext में दृश्यों और कार्यों का मानचित्रण (EF Core 2)

public class QuestionsDbContext : DbContext
{
    //...
    public DbQuery<OperativeQuestion> OperativeQuestions { get; set; }
    //...
    protected override void OnModelCreating(ModelBuilder modelBuilder)
    {
        modelBuilder.Query<OperativeQuestion>().ToView("OperativeQuestions");
    }
}
 
public static class FromSqlQueries
{
    public static IQueryable<OperativeQuestion> GetByUserEmail(this DbQuery<OperativeQuestion> source, string Email)
        => source.FromSql($"SELECT Id, Email FROM [dbo].[OperativeQuestionsUserMail] ({Email})");
}

अंतिम LINQ क्वेरी

var businessObjectsData = await context
    .OperativeQuestions
    .GetByUserEmail(Email)
    .Include(x => x.Question)
    .Select(x => x.Question)
    .SelectMany(x => x.ObjectQuestions,
                (x, bo) => new
                {
                    Id = x.Id,
                    ObjectId = bo.Object.Id,
                    ObjectTypeId = bo.Object.ObjectType.Id,
                    ObjectTypeName = bo.Object.ObjectType.Name,
                    ObjectExternalId = bo.Object.ExternalId
                })
    .ToListAsync();

निष्पादन समय का क्रम 200-800 एमएस से घटकर 2-20 एमएस आदि हो गया है, यानी दसियों गुना तेज।

अगर हम इसे और औसत रूप से लें तो हमें 350 एमएस की जगह 8 एमएस मिले।

स्पष्ट लाभों से हमें यह भी मिलता है:

पढ़ने के भार में सामान्य कमी,
अवरुद्ध होने की संभावना में उल्लेखनीय कमी
औसत अवरोधन समय को स्वीकार्य मूल्यों तक कम करना

उत्पादन

डेटाबेस कॉल का अनुकूलन और फाइन-ट्यूनिंग MS SQL के माध्यम से LINQ एक समस्या है जिसे हल किया जा सकता है.

इस काम में सावधानी और निरंतरता बहुत जरूरी है.

प्रक्रिया की शुरुआत में:

उस डेटा की जांच करना आवश्यक है जिसके साथ अनुरोध काम करता है (मान, चयनित डेटा प्रकार)
इस डेटा का उचित अनुक्रमण करें
तालिकाओं के बीच जुड़ने की शर्तों की शुद्धता की जाँच करें

अगले अनुकूलन पुनरावृत्ति से पता चलता है:

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

परिणामस्वरूप LINQ क्वेरी संरचना में पहचाने गए इष्टतम के समान होना चाहिए एसक्यूएल क्वेरी बिंदु 3 से.

स्वीकृतियाँ

साथियों को बहुत धन्यवाद jobgemws и alex_ozr कंपनी से फोर्टिस इस सामग्री को तैयार करने में सहायता के लिए।

स्रोत: www.habr.com

C#.NET में LINQ क्वेरीज़ को अनुकूलित करने की विधियाँ