C#.NET-ში LINQ მოთხოვნების ოპტიმიზაციის მეთოდები

შესავალი

В ეს მუხლი განიხილებოდა ოპტიმიზაციის ზოგიერთი მეთოდი LINQ მოთხოვნები.
აქ ასევე წარმოგიდგენთ კიდევ რამდენიმე მიდგომას კოდის ოპტიმიზაციის მიმართ LINQ მოთხოვნები.

ცნობილია, რომ LINQ(Language-Integrated Query) არის მარტივი და მოსახერხებელი ენა მონაცემთა წყაროს მოთხოვნისთვის.

А LINQ SQL-ზე არის DBMS-ში მონაცემების წვდომის ტექნოლოგია. ეს არის მძლავრი ინსტრუმენტი მონაცემებთან მუშაობისთვის, სადაც მოთხოვნები აგებულია დეკლარაციული ენის საშუალებით, რომელიც შემდეგ გადაიქცევა SQL მოთხოვნები პლატფორმა და გაგზავნილი მონაცემთა ბაზის სერვერზე შესასრულებლად. ჩვენს შემთხვევაში, DBMS-ში ვგულისხმობთ MS SQL სერვერი.

თუმცა, LINQ მოთხოვნები არ გარდაიქმნება ოპტიმალურად დაწერილებად SQL მოთხოვნები, რომელიც გამოცდილ DBA-ს შეეძლო დაეწერა ოპტიმიზაციის ყველა ნიუანსით SQL მოთხოვნები:

1. ოპტიმალური კავშირები (შემოგვიერთდით) და შედეგების გაფილტვრა (WHERE)
2. ბევრი ნიუანსი კავშირებისა და ჯგუფური პირობების გამოყენებაში
3. მრავალი ვარიაცია ჩანაცვლების პირობებში IN on არსებობსи არ არის, <> ჩართულია არსებობს
4. შედეგების შუალედური ქეშირება დროებითი ცხრილების, CTE, ცხრილის ცვლადების მეშვეობით
5. წინადადების გამოყენება (OPTION) ინსტრუქციებითა და ცხრილის მინიშნებებით WITH (...)
6. ინდექსირებული ხედების გამოყენება, როგორც ერთ-ერთი საშუალება შერჩევისას ზედმეტი მონაცემების წაკითხვისგან თავის დასაღწევად

შედეგის ძირითადი შესრულების შეფერხებები SQL მოთხოვნები შედგენისას LINQ მოთხოვნები არიან:

1. მონაცემთა შერჩევის მთელი მექანიზმის გაერთიანება ერთ მოთხოვნაში
2. კოდის იდენტური ბლოკების დუბლირება, რაც საბოლოოდ იწვევს მრავალი არასაჭირო მონაცემების წაკითხვას
3. მრავალკომპონენტიანი პირობების ჯგუფები (ლოგიკური "და" და "ან") - და и ORკომპლექსურ პირობებში გაერთიანება იწვევს იმ ფაქტს, რომ ოპტიმიზატორი, რომელსაც აქვს შესაბამისი არაკლასტერული ინდექსები საჭირო ველებისთვის, საბოლოოდ იწყებს სკანირებას კლასტერული ინდექსის მიმართ (ინდექსის სკანირება) პირობების ჯგუფების მიხედვით
4. ქვემოთხოვნების ღრმა ბუდობა პარსირებას ძალიან პრობლემურია SQL განცხადებები და შეკითხვის გეგმის ანალიზი დეველოპერების მხრიდან და DBA

ოპტიმიზაციის მეთოდები

ახლა პირდაპირ გადავიდეთ ოპტიმიზაციის მეთოდებზე.

1) დამატებითი ინდექსირება

უმჯობესია განიხილოთ ფილტრები მთავარ შერჩევის ცხრილებზე, რადგან ძალიან ხშირად მთელი მოთხოვნა აგებულია ერთი ან ორი ძირითადი ცხრილის გარშემო (აპლიკაციები-ადამიანები-ოპერაციები) და პირობების სტანდარტული ნაკრებით (დახურულია, გაუქმებული, ჩართულია, სტატუსი). მნიშვნელოვანია გამოვლენილი ნიმუშებისთვის შესაბამისი ინდექსების შექმნა.

ეს გამოსავალი აზრი აქვს, როდესაც ამ ველების არჩევა მნიშვნელოვნად ზღუდავს დაბრუნებულ კომპლექტს მოთხოვნაზე.

მაგალითად, გვაქვს 500000 2000 განაცხადი. თუმცა, მხოლოდ XNUMX აქტიური აპლიკაციაა. მაშინ სწორად შერჩეული ინდექსი დაგვიხსნის ინდექსის სკანირება დიდ მაგიდაზე და საშუალებას მოგცემთ სწრაფად აირჩიოთ მონაცემები არაკლასტერული ინდექსის საშუალებით.

ასევე, ინდექსების ნაკლებობის იდენტიფიცირება შესაძლებელია შეკითხვის გეგმების ანალიზის ან სისტემის ხედვის სტატისტიკის შეგროვების მოთხოვნის საშუალებით. MS 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 მოთხოვნები.

როგორც ცხოვრების მკაცრი პრაქტიკა გვიჩვენებს, ხშირად ბიზნესისთვის მნიშვნელოვანია ბიზნესის მახასიათებლების გარკვეული ვადების დანერგვა. და ამიტომ, მძიმე მოთხოვნები ხშირად გადადის ფონზე ქეშირებით.

ეს ნაწილობრივ გამართლებულია, რადგან მომხმარებელს ყოველთვის არ სჭირდება უახლესი მონაცემები და არსებობს მომხმარებლის ინტერფეისის რეაგირების მისაღები დონე.

ეს მიდგომა საშუალებას იძლევა გადაჭრას ბიზნესის საჭიროებები, მაგრამ საბოლოოდ ამცირებს ინფორმაციული სისტემის მუშაობას პრობლემების გადაწყვეტის უბრალოდ გადადების გზით.

ასევე უნდა გვახსოვდეს, რომ დასამატებლად საჭირო ინდექსების ძიების პროცესში, წინადადებები MS SQL ოპტიმიზაცია შეიძლება იყოს არასწორი, მათ შორის შემდეგ პირობებში:

1. თუ უკვე არის ინდექსები ველების მსგავსი ნაკრებით
2. თუ ცხრილის ველების ინდექსირება შეუძლებელია ინდექსირების შეზღუდვების გამო (უფრო დეტალურად არის აღწერილი აქ).

2) ატრიბუტების შერწყმა ერთ ახალ ატრიბუტად

ზოგჯერ ზოგიერთი ველი ერთი ცხრილიდან, რომელიც ემსახურება პირობების ჯგუფის საფუძველს, შეიძლება შეიცვალოს ერთი ახალი ველის შემოტანით.

ეს განსაკუთრებით ეხება სტატუსის ველებს, რომლებიც ჩვეულებრივ არის ბიტის ან მთელი რიცხვის ტიპის.

მაგალითი:

IsClosed = 0 და გაუქმებულია = 0 და ჩართულია = 0 შეიცვალა სტატუსი = 1.

აქ არის მთელი რიცხვის სტატუსის ატრიბუტი, რათა უზრუნველყოს, რომ ეს სტატუსები შევსებულია ცხრილში. შემდეგი, ეს ახალი ატრიბუტი ინდექსირებულია.

ეს არის მუშაობის პრობლემის ფუნდამენტური გადაწყვეტა, რადგან ჩვენ ვწვდებით მონაცემებს ზედმეტი გამოთვლების გარეშე.

3) ხედის მატერიალიზაცია

სამწუხაროდ, ში LINQ მოთხოვნები დროებითი ცხრილები, CTE-ები და ცხრილის ცვლადები პირდაპირ არ შეიძლება გამოყენებულ იქნას.

თუმცა, ამ შემთხვევისთვის ოპტიმიზაციის კიდევ ერთი გზა არსებობს - ინდექსირებული ხედები.

პირობების ჯგუფი (ზემოთ მოყვანილი მაგალითიდან) IsClosed = 0 და გაუქმებულია = 0 და ჩართულია = 0 (ან სხვა მსგავსი პირობების ნაკრები) ხდება კარგი ვარიანტი მათი ინდექსირებული ხედის გამოსაყენებლად, დიდი ნაკრებიდან მონაცემების მცირე ნაწილის ქეშირებით.

მაგრამ არსებობს მთელი რიგი შეზღუდვები ხედვის მატერიალიზაციისას:

1. ქვემოკითხვების, პუნქტების გამოყენება არსებობს უნდა შეიცვალოს გამოყენებით შემოგვიერთდით
2. თქვენ არ შეგიძლიათ გამოიყენოთ წინადადებები UNION, გაერთიანება ყველა, გამონაკლისი, ურთიერთკავშირი
3. თქვენ არ შეგიძლიათ გამოიყენოთ ცხრილის მინიშნებები და პუნქტები OPTION
4. ციკლებთან მუშაობის შესაძლებლობა არ არსებობს
5. შეუძლებელია მონაცემების ჩვენება ერთ ხედში სხვადასხვა ცხრილიდან

მნიშვნელოვანია გვახსოვდეს, რომ ინდექსირებული ხედის გამოყენების რეალური სარგებელი მიიღწევა მხოლოდ მისი რეალურად ინდექსირებით.

მაგრამ ხედის გამოძახებისას, ეს ინდექსები შეიძლება არ იყოს გამოყენებული და მათი ცალსახად გამოსაყენებლად, თქვენ უნდა მიუთითოთ WITH (NOEXPAND).

მას შემდეგ, რაც LINQ მოთხოვნები ცხრილის მინიშნებების განსაზღვრა შეუძლებელია, ასე რომ თქვენ უნდა შექმნათ სხვა წარმოდგენა - შემდეგი ფორმის „შეფუთვა“:

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

4) ცხრილის ფუნქციების გამოყენება

ხშირად შიგნით LINQ მოთხოვნები ქვემოთხოვნების დიდი ბლოკები ან ბლოკები რთული სტრუქტურის მქონე ხედების გამოყენებით ქმნიან საბოლოო მოთხოვნას ძალიან რთული და არაოპტიმალური შესრულების სტრუქტურით.

ცხრილის ფუნქციების გამოყენების ძირითადი უპირატესობები LINQ მოთხოვნები:

1. შესაძლებლობა, როგორც ხედების შემთხვევაში, იყოს გამოყენებული და მითითებული, როგორც ობიექტი, მაგრამ შეგიძლიათ გადასცეთ შეყვანის პარამეტრების ნაკრები:
   FROM FUNCTION (@param1, @param2 ...)
   შედეგად, შესაძლებელია მონაცემთა მოქნილი შერჩევის მიღწევა
2. ცხრილის ფუნქციის გამოყენების შემთხვევაში, არ არსებობს ისეთი ძლიერი შეზღუდვები, როგორც ზემოთ აღწერილი ინდექსირებული ხედების შემთხვევაში:
   1. ცხრილის მინიშნებები:
      მეშვეობით LINQ თქვენ არ შეგიძლიათ მიუთითოთ რომელი ინდექსები უნდა იყოს გამოყენებული და განსაზღვროთ მონაცემთა იზოლაციის დონე შეკითხვისას.
      მაგრამ ფუნქციას აქვს ეს შესაძლებლობები.
      ფუნქციით შეგიძლიათ მიაღწიოთ საკმაოდ მუდმივ შესრულების შეკითხვის გეგმას, სადაც განსაზღვრულია ინდექსებთან მუშაობის წესები და მონაცემთა იზოლაციის დონეები.
   2. ფუნქციის გამოყენება საშუალებას გაძლევთ, ინდექსირებულ ხედებთან შედარებით, მიიღოთ:
      • მონაცემთა შერჩევის რთული ლოგიკა (თუნდაც მარყუჟების გამოყენებით)
      • მონაცემების მიღება მრავალი სხვადასხვა ცხრილიდან
      • გამოყენების UNION и არსებობს

3. შეთავაზება OPTION ძალიან სასარგებლოა, როდესაც ჩვენ გვჭირდება კონკურენტული კონტროლის უზრუნველყოფა OPTION (MAXDOP N), შეკითხვის შესრულების გეგმის თანმიმდევრობა. Მაგალითად:
   • თქვენ შეგიძლიათ მიუთითოთ შეკითხვის გეგმის იძულებითი ხელახალი შექმნა OPTION (ხელახალი კომპილაცია)
   • შეგიძლიათ მიუთითოთ, აიძულოთ თუ არა შეკითხვის გეგმა გამოიყენოს მოთხოვნაში მითითებული შეერთების ბრძანება OPTION (იძულებითი შეკვეთა)

   მეტი დეტალი შესახებ OPTION აღწერილი აქ.

4. მონაცემთა ყველაზე ვიწრო და ყველაზე საჭირო ნაწილის გამოყენებით:
   არ არის საჭირო დიდი მონაცემთა ნაკრების შენახვა ქეშებში (როგორც ეს არის ინდექსირებული ხედების შემთხვევაში), საიდანაც ჯერ კიდევ გჭირდებათ მონაცემების გაფილტვრა პარამეტრების მიხედვით.
   მაგალითად, არის ცხრილი, რომლის ფილტრი WHERE გამოყენებულია სამი ველი (ა, ბ, გ).

   პირობითად, ყველა მოთხოვნას აქვს მუდმივი მდგომარეობა a = 0 და b = 0.

   თუმცა თხოვნა მოედანზე c უფრო ცვალებადი.

   დაუშვით პირობა a = 0 და b = 0 ეს ნამდვილად გვეხმარება შევზღუდოთ საჭირო შედეგად მიღებული ნაკრები ათასობით ჩანაწერით, მაგრამ ეს პირობაა с ავიწროებს შერჩევას ასამდე ჩანაწერამდე.

   აქ ცხრილის ფუნქცია შეიძლება იყოს უკეთესი ვარიანტი.

   ასევე, ცხრილის ფუნქცია უფრო პროგნოზირებადი და თანმიმდევრულია შესრულების დროს.

მაგალითები

მოდით შევხედოთ განხორციელების მაგალითს, მაგალითად, კითხვების მონაცემთა ბაზის გამოყენებით.

არის თხოვნა აირჩიეთ, რომელიც აერთიანებს რამდენიმე ცხრილს და იყენებს ერთ ხედს (OperativeQuestions), რომელშიც კუთვნილება მოწმდება ელექტრონული ფოსტით (მეშვეობით არსებობს) „ოპერატიულ კითხვებზე“:

მოთხოვნა No1

(@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] ხედზე, რომელიც [Email] = @p__linq__0 საშუალებას მოგვცემს შევზღუდოთ გამომავალი არჩევანი არსებობს) ასამდე ჩანაწერი.

და შეიძლება ჩანდეს, რომ ქვემოთხოვნამ უნდა გამოთვალოს ჩანაწერები ერთხელ [Email] = @p__linq__0-ით და შემდეგ ეს რამდენიმე ასეული ჩანაწერი უნდა იყოს დაკავშირებული Id-ით Questions-ით და მოთხოვნა იქნება სწრაფი.

ფაქტობრივად, არსებობს ყველა ცხრილის თანმიმდევრული კავშირი: Id Questions-ის შესაბამისობის შემოწმება Id-თან OperativeQuestions-დან და გაფილტვრა ელექტრონული ფოსტით.

სინამდვილეში, მოთხოვნა მუშაობს ათიათასობით OperativeQuestions ჩანაწერთან, მაგრამ მხოლოდ საინტერესო მონაცემებია საჭირო ელ.ფოსტის საშუალებით.

OperativeQuestions ტექსტის ნახვა:

მოთხოვნა No2

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

ამ კონკრეტულ შემთხვევაში განვიხილავთ ამ პრობლემის გადაწყვეტას ინფრასტრუქტურული ცვლილებების გარეშე, ცალკე ცხრილის შემოღების გარეშე მზა შედეგებით („აქტიური მოთხოვნები“), რომელიც საჭიროებს მონაცემთა შევსების და განახლების მექანიზმს. .

მიუხედავად იმისა, რომ ეს კარგი გამოსავალია, ამ პრობლემის ოპტიმიზაციის კიდევ ერთი ვარიანტი არსებობს.

მთავარი მიზანია ჩანაწერების ქეშირება [Email] = @p__linq__0-ით OperativeQuestions ხედიდან.

შეიყვანეთ ცხრილის ფუნქცია [dbo].[OperativeQuestionsUserMail] მონაცემთა ბაზაში.

ელ.ფოსტის, როგორც შეყვანის პარამეტრის გაგზავნით, ჩვენ ვიღებთ მნიშვნელობების ცხრილს:

მოთხოვნა No3

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-ად:

მოთხოვნა No4

(@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. დაბლოკვის საშუალო დროის დასაშვებ მნიშვნელობებამდე შემცირება

გამოყვანის

მონაცემთა ბაზის ზარების ოპტიმიზაცია და დაზუსტება MS SQL მეშვეობით LINQ არის პრობლემა, რომლის მოგვარებაც შესაძლებელია.

ამ საქმეში ძალიან მნიშვნელოვანია ყურადღება და თანმიმდევრულობა.

პროცესის დასაწყისში:

1. აუცილებელია შეამოწმოთ მონაცემები, რომლებთანაც მუშაობს მოთხოვნა (მნიშვნელობები, მონაცემთა შერჩეული ტიპები)
2. განახორციელეთ ამ მონაცემების სათანადო ინდექსირება
3. შეამოწმეთ ცხრილებს შორის შეერთების პირობების სისწორე

შემდეგი ოპტიმიზაციის გამეორება ცხადყოფს:

1. მოთხოვნის საფუძველზე და განსაზღვრავს მოთხოვნის მთავარ ფილტრს
2. მსგავსი მოთხოვნის ბლოკების გამეორება და პირობების გადაკვეთის ანალიზი
3. SSMS-ში ან სხვა GUI-ში ამისთვის SQL Server ოპტიმიზებს თავის თავს SQL შეკითხვა (მონაცემთა შუალედური საცავის გამოყოფა, მიღებული მოთხოვნის შექმნა ამ საცავის გამოყენებით (შეიძლება იყოს რამდენიმე))
4. ბოლო ეტაპზე, მიღებული საფუძვლად SQL შეკითხვა, სტრუქტურის აღდგენა მიმდინარეობს LINQ შეკითხვა

შედეგად მიღებული LINQ შეკითხვა სტრუქტურაში იდენტური უნდა იყოს გამოვლენილი ოპტიმალურის SQL შეკითხვა მე-3 წერტილიდან.

მადლობა

დიდი მადლობა კოლეგებს jobgemws и alex_ozr კომპანიისგან ფორტი ამ მასალის მომზადებაში დახმარებისთვის.

წყარო: www.habr.com