C#.NET मा LINQ क्वेरीहरू अनुकूलन गर्ने तरिकाहरू

परिचय

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

ज्ञात छ LINQ(Language-Integrated Query) डाटा स्रोत खोज्नको लागि सरल र सुविधाजनक भाषा हो।

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

यद्यपि, LINQ प्रश्नहरू इष्टतम लिखितमा रूपान्तरण हुँदैन SQL प्रश्नहरू, जुन एक अनुभवी DBA ले अप्टिमाइजेसनको सबै सूक्ष्मताहरूसँग लेख्न सक्छ SQL प्रश्नहरू:

1. इष्टतम जडानहरू (शामिल) र परिणामहरू फिल्टर गर्दै (कहाँ)
2. जडानहरू र समूह सर्तहरू प्रयोग गर्नमा धेरै सूक्ष्मताहरू
3. सर्तहरू प्रतिस्थापनमा धेरै भिन्नताहरू IN मा अवस्थितи भित्र छैन, <> अन अवस्थित
4. अस्थायी तालिकाहरू, CTE, तालिका चरहरू मार्फत परिणामहरूको मध्यवर्ती क्यासिङ
5. वाक्यको प्रयोग (विकल्प) निर्देशन र तालिका संकेतहरु संग साथ (...)
6. चयनको क्रममा अनावश्यक डेटा रिडिङबाट छुटकारा पाउनको लागि एक माध्यमको रूपमा अनुक्रमित दृश्यहरू प्रयोग गर्दै

परिणामको मुख्य प्रदर्शन बाधाहरू SQL प्रश्नहरू संकलन गर्दा LINQ प्रश्नहरू हो:

1. एक अनुरोधमा सम्पूर्ण डेटा चयन संयन्त्रको समेकन
2. कोडको समान ब्लकहरू डुप्लिकेट गर्दै, जसले अन्तत: धेरै अनावश्यक डेटा पढ्छ
3. बहु-घटक अवस्थाहरूको समूह (तार्किक "र" र "वा") - र и OR, जटिल परिस्थितिहरूमा संयोजन गर्दा, अप्टिमाइजरले आवश्यक फिल्डहरूमा उपयुक्त गैर-क्लस्टर गरिएको अनुक्रमणिका भएको तथ्यलाई निम्त्याउँछ, अन्ततः क्लस्टर गरिएको अनुक्रमणिका विरुद्ध स्क्यान गर्न थाल्छ (INDEX स्क्यानसर्तहरूको समूह द्वारा
4. सबक्वेरीहरूको गहिरो नेस्टिङले पार्सिङलाई धेरै समस्याग्रस्त बनाउँछ SQL कथनहरू र विकासकर्ताहरूको पक्षमा प्रश्न योजनाको विश्लेषण र DBA

अनुकूलन विधिहरू

अब सिधै अप्टिमाइजेसन विधिहरूमा जाऔं।

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

मुख्य छनोट तालिकाहरूमा फिल्टरहरू विचार गर्नु उत्तम हुन्छ, किनकि प्रायः सम्पूर्ण क्वेरी एक वा दुई मुख्य तालिकाहरू (एप्लिकेशन-व्यक्ति-अपरेसनहरू) र सर्तहरूको मानक सेट (IsClosed, Canceled, Enabled, Status) को वरिपरि बनाइन्छ। पहिचान गरिएका नमूनाहरूको लागि उपयुक्त सूचकहरू सिर्जना गर्न महत्त्वपूर्ण छ।

यी क्षेत्रहरू चयन गर्दा यो समाधानले महत्त्वपूर्ण रूपमा फर्काइएको सेटलाई क्वेरीमा सीमित गर्दछ।

उदाहरणका लागि, हामीसँग 500000 आवेदनहरू छन्। यद्यपि, त्यहाँ केवल 2000 सक्रिय अनुप्रयोगहरू छन्। त्यसपछि सही रूपमा चयन गरिएको अनुक्रमणिकाले हामीलाई बचाउनेछ INDEX स्क्यान ठूलो तालिकामा र तपाइँलाई गैर-क्लस्टर गरिएको अनुक्रमणिका मार्फत द्रुत रूपमा डेटा चयन गर्न अनुमति दिनेछ।

साथै, अनुक्रमणिकाको अभाव क्वेरी योजनाहरू पार्स गर्न वा प्रणाली दृश्य तथ्याङ्कहरू सङ्कलन गर्न प्रम्प्टहरू मार्फत पहिचान गर्न सकिन्छ। एमएस SQL ​​सर्वर:

1. sys.dm_db_missing_index_groups
2. sys.dm_db_missing_index_group_stats
3. sys.dm_db_missing_index_details

सबै दृश्य डेटाले हराएको अनुक्रमणिकाको बारेमा जानकारी समावेश गर्दछ, स्थानिय अनुक्रमणिका बाहेक।

यद्यपि, अनुक्रमणिका र क्यासिङ प्रायः खराब लेखिएका परिणामहरू विरुद्ध लड्ने तरिकाहरू हुन् LINQ प्रश्नहरू и SQL प्रश्नहरू.

जीवनको कठोर अभ्यासले देखाउँछ, यो प्रायः व्यापारका लागि निश्चित समयसीमाहरूमा व्यापार सुविधाहरू लागू गर्न महत्त्वपूर्ण हुन्छ। र यसैले, भारी अनुरोधहरू प्राय: क्यासिङको साथ पृष्ठभूमिमा स्थानान्तरण गरिन्छ।

यो आंशिक रूपमा जायज छ, किनकि प्रयोगकर्तालाई सधैं नवीनतम डाटा आवश्यक पर्दैन र प्रयोगकर्ता इन्टरफेसको प्रतिक्रियाको स्वीकार्य स्तर छ।

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

यो पनि सम्झना लायक छ कि आवश्यक अनुक्रमणिकाहरू खोज्ने प्रक्रियामा थप्न, सुझावहरू एमएस एसक्यूएल निम्न सर्तहरू सहित अनुकूलन गलत हुन सक्छ:

1. यदि त्यहाँ पहिले नै फिल्डहरूको समान सेट भएको अनुक्रमणिकाहरू छन्
2. यदि तालिकाका क्षेत्रहरू अनुक्रमणिका प्रतिबन्धहरूको कारणले अनुक्रमित गर्न सकिँदैन (थप विवरणमा वर्णन गरिएको छ। यहाँ).

2) विशेषताहरूलाई एक नयाँ विशेषतामा मर्ज गर्दै

कहिलेकाहीँ एउटै तालिकाबाट केही क्षेत्रहरू, जुन सर्तहरूको समूहको लागि आधारको रूपमा काम गर्दछ, एउटा नयाँ क्षेत्र प्रस्तुत गरेर प्रतिस्थापन गर्न सकिन्छ।

यो विशेष गरी स्थिति क्षेत्रहरूको लागि सत्य हो, जुन सामान्यतया बिट वा पूर्णांक प्रकारमा हुन्छ।

उदाहरण:

बन्द = ० र रद्द = ० र सक्षम = ० द्वारा प्रतिस्थापित गरिएको छ स्थिति = 1.

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

यो कार्यसम्पादन समस्याको आधारभूत समाधान हो, किनकि हामी अनावश्यक गणना बिना डेटा पहुँच गर्छौं।

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

दुर्भाग्यवश, मा LINQ प्रश्नहरू अस्थायी तालिकाहरू, CTEs, र तालिका चरहरू सीधा प्रयोग गर्न सकिँदैन।

यद्यपि, यस केसको लागि अनुकूलन गर्ने अर्को तरिका छ - अनुक्रमित दृश्यहरू।

अवस्था समूह (माथिको उदाहरणबाट) बन्द = ० र रद्द = ० र सक्षम = ० (वा अन्य समान अवस्थाहरूको सेट) तिनीहरूलाई अनुक्रमणिका दृश्यमा प्रयोग गर्नको लागि राम्रो विकल्प बन्छ, ठूलो सेटबाट डाटाको सानो टुक्रा क्यास गर्दै।

तर दृश्यलाई साकार गर्दा त्यहाँ धेरै प्रतिबन्धहरू छन्:

1. सबक्वेरीहरू, क्लजहरू प्रयोग गर्दै अवस्थित प्रयोग गरेर प्रतिस्थापन गर्नुपर्छ शामिल
2. तपाईं वाक्यहरू प्रयोग गर्न सक्नुहुन्न यूनियन, यूनियन सबै, बहिष्कार, इन्टरसेक्ट
3. तपाइँ तालिका संकेत र खण्डहरू प्रयोग गर्न सक्नुहुन्न विकल्प
4. साइकलसँग काम गर्ने सम्भावना छैन
5. विभिन्न तालिकाहरूबाट एक दृश्यमा डेटा प्रदर्शन गर्न असम्भव छ

यो याद राख्नु महत्त्वपूर्ण छ कि अनुक्रमणिका दृश्य प्रयोग गर्ने वास्तविक लाभ वास्तवमा अनुक्रमणिका गरेर मात्र प्राप्त गर्न सकिन्छ।

तर एक दृश्य कल गर्दा, यी अनुक्रमणिकाहरू प्रयोग गर्न सकिँदैन, र तिनीहरूलाई स्पष्ट रूपमा प्रयोग गर्न, तपाईंले निर्दिष्ट गर्नुपर्छ (NOEXPAND) सँग.

सन् २०० देखि LINQ प्रश्नहरू तालिका संकेतहरू परिभाषित गर्न असम्भव छ, त्यसैले तपाईंले अर्को प्रतिनिधित्व सिर्जना गर्नुपर्नेछ - निम्न फारमको "रेपर":

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

4) तालिका प्रकार्यहरू प्रयोग गर्दै

अक्सर मा LINQ प्रश्नहरू सबक्वेरीका ठूला ब्लकहरू वा जटिल संरचना भएका दृश्यहरू प्रयोग गरेर ब्लकहरूले धेरै जटिल र सबोप्टिमल कार्यान्वयन संरचनाको साथ अन्तिम क्वेरी बनाउँछन्।

मा तालिका प्रकार्यहरू प्रयोग गर्ने मुख्य फाइदाहरू LINQ प्रश्नहरू:

1. क्षमता, दृश्य को मामला मा, प्रयोग गर्न र वस्तु को रूप मा निर्दिष्ट गर्न को लागी, तर तपाईले इनपुट प्यारामिटरहरु को एक सेट पास गर्न सक्नुहुन्छ:
   फंक्शनबाट (@param1, @param2 ...)
   नतिजाको रूपमा, लचिलो डाटा नमूना प्राप्त गर्न सकिन्छ
2. तालिका प्रकार्य प्रयोग गर्ने सन्दर्भमा, माथि वर्णन गरिएको अनुक्रमणिका दृश्यहरूको मामलामा कुनै पनि कडा प्रतिबन्धहरू छैनन्:
   1. तालिका संकेत:
      मार्फत LINQ तपाईले कुन अनुक्रमणिकाहरू प्रयोग गर्नुपर्छ र क्वेरी गर्दा डेटा अलगाव स्तर निर्धारण गर्न सक्नुहुन्न।
      तर प्रकार्यमा यी क्षमताहरू छन्।
      प्रकार्यको साथ, तपाइँ एक पर्याप्त स्थिर कार्यान्वयन क्वेरी योजना प्राप्त गर्न सक्नुहुन्छ, जहाँ अनुक्रमणिका र डेटा अलगाव स्तरहरूसँग काम गर्ने नियमहरू परिभाषित छन्।
   2. प्रकार्य प्रयोग गरेर, अनुक्रमित दृश्यहरूको तुलनामा, प्राप्त गर्न अनुमति दिन्छ:
      • जटिल डाटा नमूना तर्क (लूप प्रयोग गरेर पनि)
      • धेरै फरक तालिकाहरूबाट डाटा प्राप्त गर्दै
      • को प्रयोग यूनियन и अवस्थित

3. प्रस्ताव विकल्प धेरै उपयोगी छ जब हामी concurrency नियन्त्रण प्रदान गर्न आवश्यक छ OPTION(MAXDOP N), क्वेरी कार्यान्वयन योजना को क्रम। उदाहरणका लागि:
   • तपाईंले क्वेरी योजनाको जबरजस्ती पुन: सिर्जना निर्दिष्ट गर्न सक्नुहुन्छ विकल्प (पुनः कम्पाइल)
   • तपाईंले क्वेरीमा निर्दिष्ट गरिएको सामेल आदेश प्रयोग गर्न क्वेरी योजनालाई जबरजस्ती गर्ने कि भनेर निर्दिष्ट गर्न सक्नुहुन्छ विकल्प (फोर्स अर्डर)

   बारे थप विवरण विकल्प वर्णन गरिएको यहाँ.

4. साँघुरो र सबैभन्दा आवश्यक डाटा स्लाइस प्रयोग गर्दै:
   क्यासहरूमा ठूला डेटा सेटहरू भण्डारण गर्न आवश्यक छैन (जस्तै अनुक्रमित दृश्यहरूको मामला हो), जहाँबाट तपाईंले अझै पनि प्यारामिटरद्वारा डाटा फिल्टर गर्न आवश्यक छ।
   उदाहरणका लागि, त्यहाँ एउटा तालिका छ जसको फिल्टर कहाँ तीन क्षेत्रहरू प्रयोग गरिन्छ (ए बी सी).

   परम्परागत रूपमा, सबै अनुरोधहरूको स्थिर अवस्था हुन्छ a = 0 र b = 0.

   यद्यपि, क्षेत्रको लागि अनुरोध c अधिक चर।

   शर्त राखौं a = 0 र b = 0 यसले हामीलाई आवश्यक नतिजालाई हजारौं रेकर्डहरूमा सीमित गर्न मद्दत गर्दछ, तर सर्तमा с एक सय रेकर्डमा चयनलाई संकुचित गर्दछ।

   यहाँ तालिका प्रकार्य एक राम्रो विकल्प हुन सक्छ।

   साथै, तालिका प्रकार्य कार्यान्वयन समय मा अधिक अनुमानित र लगातार छ।

उदाहरण

उदाहरणको रूपमा प्रश्न डेटाबेस प्रयोग गरेर उदाहरण कार्यान्वयनलाई हेरौं।

अनुरोध छ चयन गर्नुहोस्, जसले धेरै तालिकाहरू संयोजन गर्दछ र एउटा दृश्य (अपरेटिभ प्रश्नहरू) प्रयोग गर्दछ, जसमा इमेलद्वारा सम्बद्धता जाँच गरिन्छ (मार्फत अवस्थित) "अपरेटिभ प्रश्नहरू" लाई:

अनुरोध नम्बर १

(@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])
));

दृश्यको बरु जटिल संरचना छ: यसमा सबक्वेरी जोडिएको छ र क्रमबद्ध गर्ने प्रयोग गर्दछ भिन्न, जुन सामान्यतया एक पर्याप्त संसाधन-गहन सञ्चालन हो।

OperativeQuestions को एक नमूना लगभग दस हजार रेकर्ड छ।

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

र यस्तो लाग्न सक्छ कि सबक्वेरीले [इमेल] = @p__linq__0 द्वारा एक पटक रेकर्डहरू गणना गर्नुपर्छ, र त्यसपछि यी दुई सय रेकर्डहरू प्रश्नहरूको साथ आईडीद्वारा जडान हुनुपर्छ, र क्वेरी छिटो हुनेछ।

वास्तवमा, त्यहाँ सबै तालिकाहरूको अनुक्रमिक जडान छ: अपरेटिभ प्रश्नहरूबाट आईडीको साथ आईडी प्रश्नहरूको पत्राचार जाँच गर्दै, र इमेलद्वारा फिल्टर गर्ने।

वास्तवमा, अनुरोधले सबै दशौं हजार अपरेटिभ प्रश्न रेकर्डहरूसँग काम गर्दछ, तर इमेल मार्फत रुचिको डेटा मात्र आवश्यक छ।

परिचालन प्रश्नहरू पाठ हेर्नुहोस्:

अनुरोध नम्बर १

 
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 कोर 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] परिचय गर्नुहोस्।

इनपुट प्यारामिटरको रूपमा इमेल पठाएर, हामीले मानहरूको तालिका फिर्ता पाउँछौं:

अनुरोध नम्बर १

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

यसले पूर्वनिर्धारित डेटा संरचनाको साथ मानहरूको तालिका फर्काउँछ।

OperativeQuestionsUserMail को प्रश्नहरू इष्टतम हुन र इष्टतम क्वेरी योजनाहरू हुनको लागि, कडा संरचना आवश्यक छ, र होइन। रिटर्नको रूपमा तालिका फर्काउँछ...

यस अवस्थामा, आवश्यक क्वेरी 1 लाई क्वेरी 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 ms बाट 2-20 ms, इत्यादिमा झरेको छ, अर्थात् दशौं गुणा छिटो।

यदि हामीले यसलाई बढी औसत रूपमा लियौं भने, 350 ms को सट्टा हामीले 8 ms पायौं।

स्पष्ट फाइदाहरूबाट हामी पनि पाउँछौं:

1. पढ्ने भारमा सामान्य कमी,
2. अवरुद्ध को संभावना मा महत्वपूर्ण कमी
3. स्वीकार्य मानहरूमा औसत अवरुद्ध समय घटाउँदै

निष्कर्षमा

डाटाबेस कलहरूको अप्टिमाइजेसन र फाइन-ट्यूनिङ एमएस एसक्यूएल मार्फत LINQ समाधान गर्न सकिने समस्या हो।

यस कार्यमा ध्यान र निरन्तरता धेरै महत्त्वपूर्ण छ।

प्रक्रियाको सुरुमा:

1. अनुरोध काम गर्ने डेटा जाँच गर्न आवश्यक छ (मान, चयन गरिएको डेटा प्रकारहरू)
2. यस डाटाको उचित अनुक्रमणिका पूरा गर्नुहोस्
3. तालिकाहरू बीच जोडिने अवस्थाहरूको शुद्धता जाँच गर्नुहोस्

अर्को अप्टिमाइजेसन पुनरावृत्तिले बताउँछ:

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

नतिजा LINQ क्वेरी पहिचान गरिएको इष्टतमको संरचनामा समान हुनुपर्छ SQL क्वेरी बिन्दु 3 बाट।

स्वीकार

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

स्रोत: www.habr.com