ProHoster > Blog > Administracja > Niektóre aspekty optymalizacji zapytań LINQ w C#.NET dla MS SQL Server

Niektóre aspekty optymalizacji zapytań LINQ w C#.NET dla MS SQL Server

LINQ wszedł do .NET jako nowy potężny język manipulacji danymi. LINQ to SQL, jako jego część, umożliwia wygodne komunikowanie się z bazami danych, na przykład za pomocą Entity Framework. Jednakże, często stosując go, programiści zapominają zwracać uwagę na to, jaki dokładnie zapytanie SQL wygeneruje dostawca queryable, w twoim przypadku — Entity Framework.

Omówimy dwa główne aspekty na przykładzie.
W tym celu w SQL Server stworzymy bazę danych Test, a w niej utworzymy dwie tabele za pomocą następującego zapytania:

Tworzenie tabel

USE [TEST]
GO

SET ANSI_NULLS ON
GO

SET QUOTED_IDENTIFIER ON
GO

CREATE TABLE [dbo].[Ref](
	[ID] [int] NOT NULL,
	[ID2] [int] NOT NULL,
	[Name] [nvarchar](255) NOT NULL,
	[InsertUTCDate] [datetime] NOT NULL,
 CONSTRAINT [PK_Ref] PRIMARY KEY CLUSTERED 
(
	[ID] ASC
)WITH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, IGNORE_DUP_KEY = OFF, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON) ON [PRIMARY]
) ON [PRIMARY]
GO

ALTER TABLE [dbo].[Ref] ADD  CONSTRAINT [DF_Ref_InsertUTCDate]  DEFAULT (getutcdate()) FOR [InsertUTCDate]
GO

USE [TEST]
GO

SET ANSI_NULLS ON
GO

SET QUOTED_IDENTIFIER ON
GO

CREATE TABLE [dbo].[Customer](
	[ID] [int] NOT NULL,
	[Name] [nvarchar](255) NOT NULL,
	[Ref_ID] [int] NOT NULL,
	[InsertUTCDate] [datetime] NOT NULL,
	[Ref_ID2] [int] NOT NULL,
 CONSTRAINT [PK_Customer] PRIMARY KEY CLUSTERED 
(
	[ID] ASC
)WITH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, IGNORE_DUP_KEY = OFF, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON) ON [PRIMARY]
) ON [PRIMARY]
GO

ALTER TABLE [dbo].[Customer] ADD  CONSTRAINT [DF_Customer_Ref_ID]  DEFAULT ((0)) FOR [Ref_ID]
GO

ALTER TABLE [dbo].[Customer] ADD  CONSTRAINT [DF_Customer_InsertUTCDate]  DEFAULT (getutcdate()) FOR [InsertUTCDate]
GO

Teraz wypełnimy tabelę Ref, uruchamiając następujący skrypt:

Wypełnianie tabeli Ref

USE [TEST]
GO

DECLARE @ind INT=1;

WHILE(@ind<1200000)
BEGIN
	INSERT INTO [dbo].[Ref]
           ([ID]
           ,[ID2]
           ,[Name])
    SELECT
           @ind
           ,@ind
           ,CAST(@ind AS NVARCHAR(255));

	SET @ind=@ind+1;
END 
GO

Podobnie wypełnimy tabelę Customer za pomocą następującego skryptu:

Wypełnianie tabeli Customer

UŻYJ [TEST]
GO

DECLARE @ind INT=1;
DECLARE @ind_ref INT=1;

WHILE(@ind<=12000000)
BEGIN
	IF(@ind%3=0) SET @ind_ref=1;
	ELSE IF (@ind%5=0) SET @ind_ref=2;
	ELSE IF (@ind%7=0) SET @ind_ref=3;
	ELSE IF (@ind=0) SET @ind_ref=4;
	ELSE IF (@ind=0) SET @ind_ref=5;
	ELSE IF (@ind=0) SET @ind_ref=6;
	ELSE IF (@ind=0) SET @ind_ref=7;
	ELSE IF (@ind=0) SET @ind_ref=8;
	ELSE IF (@ind=0) SET @ind_ref=9;
	ELSE IF (@ind=0) SET @ind_ref=10;
	ELSE IF (@ind=0) SET @ind_ref=11;
	ELSE SET @ind_ref=@ind90000;
	
	INSERT INTO [dbo].[Customer]
	 ([ID]
	 ,[Name]
	 ,[Ref_ID]
	 ,[Ref_ID2])
	 SELECT
	 @ind,
	 CAST(@ind AS NVARCHAR(255)),
	 @ind_ref,
	 @ind_ref;


	SET @ind=@ind+1;
END
GO

W ten sposób uzyskaliśmy dwie tabele, w jednej z nich jest ponad 1 milion wierszy danych, a w drugiej - ponad 10 milionów wierszy danych.

Teraz w Visual Studio należy stworzyć projekt testowy Visual C# Console App (.NET Framework):

Niektóre aspekty optymalizacji zapytań LINQ w C#.NET dla MS SQL Server

Następnie, należy dodać bibliotekę do Entity Framework w celu interakcji z bazą danych.
Aby dodać, kliknij prawym przyciskiem myszy na projekcie i wybierz w menu kontekstowym Zarządzaj pakietami NuGet:

Niektóre aspekty optymalizacji zapytań LINQ w C#.NET dla MS SQL Server

Następnie w otwartym oknie zarządzania pakietami NuGet w polu wyszukiwania wpisz słowo „Entity Framework”, wybierz pakiet Entity Framework i zainstaluj go:

Niektóre aspekty optymalizacji zapytań LINQ w C#.NET dla MS SQL Server

Następnie w pliku App.config, po zamknięciu elementu configSections, należy dodać następujący blok:

W connectionString należy wpisać łańcuch połączeniowy.

Teraz utworzymy w osobnych plikach 3 interfejsy:

  1. Implementacja interfejsu IBaseEntityID
    namespace TestLINQ
{
    public interface IBaseEntityID
    {
        int ID { get; set; }
    }
}

  2. Implementacja interfejsu IBaseEntityName
    namespace TestLINQ
{
    public interface IBaseEntityName
    {
        string Name { get; set; }
    }
}

  3. Implementacja interfejsu IBaseNameInsertUTCDate
    namespace TestLINQ
{
    public interface IBaseNameInsertUTCDate
    {
        DateTime InsertUTCDate { get; set; }
    }
}

A w osobnym pliku utworzymy klasę bazową BaseEntity dla naszych dwóch encji, która będzie zawierać wspólne pola:

Implementacja klasy bazowej BaseEntity

namespace TestLINQ
{
    public class BaseEntity : IBaseEntityID, IBaseEntityName, IBaseNameInsertUTCDate
    {
        public int ID { get; set; }
        public string Name { get; set; }
        public DateTime InsertUTCDate { get; set; }
    }
}

Następnie w osobnych plikach utworzymy nasze dwie encje:

  1. Implementacja klasy Ref
    using System.ComponentModel.DataAnnotations.Schema;

namespace TestLINQ
{
    [Table("Ref")]
    public class Ref : BaseEntity
    {
        public int ID2 { get; set; }
    }
}

  2. Implementacja klasy Customer
    using System.ComponentModel.DataAnnotations.Schema;

namespace TestLINQ
{
    [Table("Customer")]
    public class Customer: BaseEntity
    {
        public int Ref_ID { get; set; }
        public int Ref_ID2 { get; set; }
    }
}

Teraz utworzymy w osobnym pliku kontekst UserContext:

Implementacja klasy UserContext

using System.Data.Entity;

namespace TestLINQ
{
    public class UserContext : DbContext
    {
        public UserContext()
            : base("DbConnection")
        {
            Database.SetInitializer(null);
        }

        public DbSet Customer { get; set; }
        public DbSet Ref { get; set; }
    }
}

Uzyskaliśmy gotowe rozwiązanie do przeprowadzania testów optymalizacji za pomocą LINQ to SQL przez EF dla MS SQL Server:

Niektóre aspekty optymalizacji zapytań LINQ w C#.NET dla MS SQL Server

Teraz w pliku Program.cs wprowadź następujący kod:

Plik Program.cs

using System;
using System.Collections.Generic;
using System.Linq;

namespace TestLINQ
{
    class Program
    {
        static void Main(string[] args)
        {
            using (UserContext db = new UserContext())
            {
                var dblog = new List();
                db.Database.Log = dblog.Add;

                var query = from e1 in db.Customer
                            from e2 in db.Ref
                            where (e1.Ref_ID == e2.ID)
                                 && (e1.Ref_ID2 == e2.ID2)
                            select new { Data1 = e1.Name, Data2 = e2.Name };

                var result = query.Take(1000).ToList();

                Console.WriteLine(dblog[1]);

                Console.ReadKey();
            }
        }
    }
}

Następnie uruchomimy nasz projekt.

Na koniec w konsoli zostanie wyświetlone:

Wygenerowane zapytanie SQL

SELECT TOP (1000) 
    [Extent1].[Ref_ID] AS [Ref_ID], 
    [Extent1].[Name] AS [Name], 
    [Extent2].[Name] AS [Name1]
    FROM  [dbo].[Customer] AS [Extent1]
    INNER JOIN [dbo].[Ref] AS [Extent2] ON ([Extent1].[Ref_ID] = [Extent2].[ID]) AND ([Extent1].[Ref_ID2] = [Extent2].[ID2])

Tzn. ogólnie rzecz biorąc, zapytanie LINQ wygenerowało całkiem niezłe zapytanie SQL do systemu MS SQL Server.

Teraz zmienimy warunek AND na OR w zapytaniu LINQ:

zapytanie LINQ

var query = from e1 in db.Customer
                            from e2 in db.Ref
                            where (e1.Ref_ID == e2.ID)
                                || (e1.Ref_ID2 == e2.ID2)
                            select new { Data1 = e1.Name, Data2 = e2.Name };

I znowu uruchomimy naszą aplikację.

Wykonanie zakończy się błędem związanym z przekroczeniem czasu wykonania zlecenia 30 sek:

Niektóre aspekty optymalizacji zapytań LINQ w C#.NET dla MS SQL Server

Jeśli spojrzymy, jakie zapytanie zostało wygenerowane przez LINQ:

Niektóre aspekty optymalizacji zapytań LINQ w C#.NET dla MS SQL Server
, możemy się przekonać, że pobieranie danych odbywa się poprzez iloczyn kartezjański dwóch zbiorów (tabel):

Wygenerowane zapytanie SQL

SELECT TOP (1000) 
    [Extent1].[Ref_ID] AS [Ref_ID], 
    [Extent1].[Name] AS [Name], 
    [Extent2].[Name] AS [Name1]
    FROM  [dbo].[Customer] AS [Extent1]
    CROSS JOIN [dbo].[Ref] AS [Extent2]
    WHERE [Extent1].[Ref_ID] = [Extent2].[ID] OR [Extent1].[Ref_ID2] = [Extent2].[ID2]

Przepiszmy zapytanie LINQ w ten sposób:

Optymalizowane zapytanie LINQ

var query = (from e1 in db.Customer
                   join e2 in db.Ref
                   on e1.Ref_ID equals e2.ID
                   select new { Data1 = e1.Name, Data2 = e2.Name }).Union(
                        from e1 in db.Customer
                        join e2 in db.Ref
                        on e1.Ref_ID2 equals e2.ID2
                        select new { Data1 = e1.Name, Data2 = e2.Name });

Wtedy uzyskamy następujące zapytanie SQL:

zapytanie SQL

SELECT 
    [Limit1].[C1] AS [C1], 
    [Limit1].[C2] AS [C2], 
    [Limit1].[C3] AS [C3]
    FROM ( SELECT DISTINCT TOP (1000) 
        [UnionAll1].[C1] AS [C1], 
        [UnionAll1].[Name] AS [C2], 
        [UnionAll1].[Name1] AS [C3]
        FROM  (SELECT 
            1 AS [C1], 
            [Extent1].[Name] AS [Name], 
            [Extent2].[Name] AS [Name1]
            FROM  [dbo].[Customer] AS [Extent1]
            INNER JOIN [dbo].[Ref] AS [Extent2] ON [Extent1].[Ref_ID] = [Extent2].[ID]
        UNION ALL
            SELECT 
            1 AS [C1], 
            [Extent3].[Name] AS [Name], 
            [Extent4].[Name] AS [Name1]
            FROM  [dbo].[Customer] AS [Extent3]
            INNER JOIN [dbo].[Ref] AS [Extent4] ON [Extent3].[Ref_ID2] = [Extent4].[ID2]) AS [UnionAll1]
    )  AS [Limit1]

Niestety, w zapytaniach LINQ warunek łączenia może być tylko jeden, dlatego można wykonać równoważne zapytanie poprzez dwa zapytania dla każdego warunku, a następnie połączyć je za pomocą Union, aby usunąć duplikaty wierszy.
Tak, w ogólnym przypadku zapytania będą nieequiwalentne, ponieważ mogą zwracać pełne duplikaty wierszy. Jednak w rzeczywistości pełne dupliki są niepotrzebne i staramy się ich unikać.

Teraz porównajmy plany wykonania tych dwóch zapytań:

  1. dla CROSS JOIN średni czas wykonania wynosi 195 sek:
    Niektóre aspekty optymalizacji zapytań LINQ w C#.NET dla MS SQL Server
  2. dla INNER JOIN-UNION średni czas wykonania wynosi mniej niż 24 sek:
    Niektóre aspekty optymalizacji zapytań LINQ w C#.NET dla MS SQL Server

Jak widać z wyników, dla dwóch tabel z milionami rekordów zoptymalizowane zapytanie LINQ działa wielokrotnie szybciej niż nieoptymalizowane.

Dla wariantu z AND w warunkach zapytania LINQ w postaci:

zapytanie LINQ

var query = from e1 in db.Customer
                            from e2 in db.Ref
                            where (e1.Ref_ID == e2.ID)
                                 && (e1.Ref_ID2 == e2.ID2)
                            select new { Data1 = e1.Name, Data2 = e2.Name };

niemal zawsze będzie generowane poprawne zapytanie SQL, które będzie się wykonywać średnio około 1 sek:

Niektóre aspekty optymalizacji zapytań LINQ w C#.NET dla MS SQL Server
Również dla manipulacji LINQ to Objects zamiast zapytania w postaci:

Zapytanie LINQ (wariant 1)

var query = from e1 in seq1
                            from e2 in seq2
                            where (e1.Key1==e2.Key1)
                               && (e1.Key2==e2.Key2)
                            select new { Data1 = e1.Data, Data2 = e2.Data };

można użyć zapytania w postaci:

Zapytanie LINQ (wariant 2)

var query = from e1 in seq1
                            join e2 in seq2
                            on new { e1.Key1, e1.Key2 } equals new { e2.Key1, e2.Key2 }
                            select new { Data1 = e1.Data, Data2 = e2.Data };

gdzie:

Definiowanie dwóch tablic

Para[] seq1 = new[] { new Para { Key1 = 1, Key2 = 2, Data = "777" }, new Para { Key1 = 2, Key2 = 3, Data = "888" }, new Para { Key1 = 3, Key2 = 4, Data = "999" } };
Para[] seq2 = new[] { new Para { Key1 = 1, Key2 = 2, Data = "777" }, new Para { Key1 = 2, Key2 = 3, Data = "888" }, new Para { Key1 = 3, Key2 = 5, Data = "999" } };

, a typ Para jest określany w następujący sposób:

Definicja typu Para

class Para
{
        public int Key1, Key2;
        public string Data;
}

W ten sposób omówiliśmy pewne aspekty optymalizacji zapytań LINQ do MS SQL Server.

Niestety, nawet doświadczeni i wiodący programiści .NET zapominają, że należy rozumieć, co się dzieje w tle z tymi instrukcjami, których używają. W przeciwnym razie stają się konfiguratorami i mogą wprowadzić bombę zegarową w przyszłości, zarówno przy skalowaniu rozwiązania programowego, jak i przy niewielkich zmianach warunków zewnętrznych.

Przeprowadzono także krótki przegląd i tutaj.

Źródła do testów — sam projekt, tworzenie tabel w bazie danych TEST, a także wypełnianie tych tabel danymi znajduje się tutaj.
W tym repozytorium w folderze Plans znajdują się plany realizacji zapytań z warunkami OR.

Źródło: habr.com

Kup solidny hosting stron z ochroną przed DDoS, serwery VPS VDS 🔥 Kup solidny hosting stron z ochroną przed DDoS, serwery VPS VDS | ProHoster