LINQ увайшоў у .NET як новы магутны мову маніпуляцыі з дадзенымі. LINQ to SQL як частка яго дазваляе досыць зручна мець зносіны з СКБД з дапамогай напрыклад Entity Framework. Аднак, досыць часта ужываючы яго, распрацоўнікі забываюць глядзець на тое, які менавіта SQL-запыт будзе генераваць queryable provider, у вашым выпадку – Entity Framework.
Разбярэм два асноўныя моманты на прыкладзе.
Для гэтага ў SQL Server створым базу дадзеных Test, а ў ёй створым дзве табліцы з дапамогай наступнага запыту:
Стварэнне табліц
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
Цяпер запоўнім табліцу Ref з дапамогай запуску наступнага скрыпту:
Запаўненне табліцы 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
Аналагічна запоўнім табліцу Customer з дапамогай наступнага скрыпту:
Запаўненне табліцы Customer
USE [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%11=0) SET @ind_ref=4;
ELSE IF (@ind%13=0) SET @ind_ref=5;
ELSE IF (@ind%17=0) SET @ind_ref=6;
ELSE IF (@ind%19=0) SET @ind_ref=7;
ELSE IF (@ind%23=0) SET @ind_ref=8;
ELSE IF (@ind%29=0) SET @ind_ref=9;
ELSE IF (@ind%31=0) SET @ind_ref=10;
ELSE IF (@ind%37=0) SET @ind_ref=11;
ELSE SET @ind_ref=@ind%1190000;
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
Такім чынам мы атрымалі дзве табліцы, у адной з якіх больш за 1 млн радкоў дадзеных, а ў іншай-больш за 10 млн радкоў дадзеных.
Зараз у Visual Studio неабходна стварыць тэставы праект Visual C# Console App (.NET Framework):
Далей, неабходна для ўзаемадзеяння з базай даных дадаць бібліятэку для Entity Framework.
Каб яе дадаць, націснем на праект правай кнопкай мышы і абярэм у кантэкстным меню Manage NuGet Packages:
Затым у якое з'явілася акне кіравання NuGet-пакетамі ў акне пошуку ўвядзем слова "Entity Framework" і абярэм пакет Entity Framework і ўсталюем яго:
Далей у файле App.config пасля зачынення элемента configSections неабходна дадаць наступны блок:
<connectionStrings>
<add name="DBConnection" connectionString="data source=ИМЯ_ЭКЗЕМПЛЯРА_MSSQL;Initial Catalog=TEST;Integrated Security=True;" providerName="System.Data.SqlClient" />
</connectionStrings>
У connectionString трэба ўпісаць радок падключэння.
Цяпер створым у асобных файлах 3 інтэрфейсы:
- Рэалізацыя інтэрфейсу IBaseEntityID
namespace TestLINQ { public interface IBaseEntityID { int ID { get; set; } } } - Рэалізацыя інтэрфейсу IBaseEntityName
namespace TestLINQ { public interface IBaseEntityName { string Name { get; set; } } } - Рэалізацыя інтэрфейсу IBaseNameInsertUTCDate
namespace TestLINQ { public interface IBaseNameInsertUTCDate { DateTime InsertUTCDate { get; set; } } }
І ў асобным файле створым базавы клас BaseEntity для нашых двух сутнасцяў, у які ўвойдуць агульныя палі:
Рэалізацыя базавага класа BaseEntity
namespace TestLINQ
{
public class BaseEntity : IBaseEntityID, IBaseEntityName, IBaseNameInsertUTCDate
{
public int ID { get; set; }
public string Name { get; set; }
public DateTime InsertUTCDate { get; set; }
}
}
Далей у асобных файлах створым нашы дзве сутнасці:
- Рэалізацыя класа Ref
using System.ComponentModel.DataAnnotations.Schema; namespace TestLINQ { [Table("Ref")] public class Ref : BaseEntity { public int ID2 { get; set; } } } - Рэалізацыя класа 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; } } }
Цяпер створым у асобным файле кантэкст UserContext:
Рэалізацыя класа UserContex
using System.Data.Entity;
namespace TestLINQ
{
public class UserContext : DbContext
{
public UserContext()
: base("DbConnection")
{
Database.SetInitializer<UserContext>(null);
}
public DbSet<Customer> Customer { get; set; }
public DbSet<Ref> Ref { get; set; }
}
}
Атрымалі гатовае рашэнне для правядзення тэстаў па аптымізацыі з LINQ to SQL праз EF для MS SQL Server:
Цяпер у файл Program.cs увядзем наступны код:
Файл 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<string>();
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();
}
}
}
}
Далей запусцім наш праект.
У канцы працы на кансоль будзе выведзена:
Згенераваны 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])
Т. е. у цэлым вельмі нядрэнна LINQ-запыт згенераваў SQL-запыт да СКБД MS SQL Server.
Цяпер зменім умову І на АБО у LINQ-запыце:
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 };
І зноў запусцім наша дадатак.
Выкананне вылеціць з памылкай, звязанай з перавышэннем часу выканання каманды ў 30 сек.
Калі паглядзець які запыт пры гэтым быў згенераваны LINQ:
, то можна пераканацца ў тым, што выбарка адбываецца праз дэкартавы твор двух мностваў (табліц):
Згенераваны 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]
Давайце перапішам LINQ-запыт наступным чынам:
Аптымізаваны 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 });
Тады атрымаем наступны SQL-запыт:
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]
Нажаль, але ў LINQ-запытах умова злучэння можа быць толькі адна, таму тут магчыма зрабіць эквівалентны запыт праз два запыты па кожнай умове з наступным аб'яднаннем іх праз Union для выдалення дублікатаў сярод радкоў.
Так, запыты ў агульным выпадку атрымаюцца неэквівалентнымі з тым улікам, што могуць быць вернуты поўныя дублікаты радкоў. Аднак, у рэальным жыцці поўныя дублюючыя радкі не патрэбны і ад іх імкнуцца пазбаўляцца.
Цяпер параўнаем планы выканання двух гэтых запытаў:
- для CROSS JOIN у сярэднім час выканання 195 сек:
- для INNER JOIN-UNION у сярэднім час выканання менш за 24 сек:
Як відаць з вынікаў, для двух табліц з мільёнамі запісаў аптымізаваны LINQ-запыт працуе ў разы хутчэй, чым неаптымізаваны.
Для варыянту з І ва ўмовах LINQ-запыт выгляду:
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 };
амаль заўсёды будзе згенераваны правільны SQL-запыт, які будзе выконвацца ў сярэднім прыкладна 1 сек:
Таксама для маніпуляцый LINQ to Objects замест запыту віду:
LINQ-запыт (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 };
можна выкарыстоўваць запыт выгляду:
LINQ-запыт (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 };
дзе:
Вызначэнне двух масіваў
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" } };
, а тып Para вызначаецца наступным чынам:
Вызначэнне тыпу Para
class Para
{
public int Key1, Key2;
public string Data;
}
Такім чынам, мы разгледзелі некаторыя аспекты ў аптымізацыі LINQ-запытаў да MS SQL Server.
Нажаль нават дасведчаныя і кіроўныя .NET-распрацоўнікі забываюць аб тым, што неабходна разумець што робяць за кадрам тыя інструкцыі, якія яны выкарыстаюць. Інакш яны становяцца канфігуратарамі і могуць закласці бомбу запаволенага дзеяння ў будучыні як пры маштабаванні праграмнага рашэння, так і пры малаважных зменах вонкавых умоў асяроддзя.
Таксама невялікі агляд праводзіўся і .
Зыходнікі для тэсту-сам праект, стварэнне табліц у базе дадзеных TEST, а таксама напаўненне дадзенымі гэтых табліц знаходзіцца .
Таксама ў гэтым рэпазітары ў тэчцы Plans знаходзяцца планы выканання запытаў з умовамі АБО.
Крыніца: habr.com