这篇 MSDN 文章列出了一系列提高 Entity Framework 性能的方法:
https://msdn.microsoft.com/en-us/data/hh949853.aspx
它的建议(4.3)之一是将非映射对象的属性转换为局部变量，以便 EF 可以缓存其内部查询计划。
这主意听起来很不错。因此，我使用一个简单的查询对其进行了测试，该查询将查询中间接属性引用的 10,000 次迭代与局部变量的性能进行了比较。像这样:
[Fact]
public void TestQueryCaching()
{
const int iterations = 1000;
var quote = new Quote();
using (var ctx = new CoreContext())
{
quote.QuoteId = ctx.Quotes.First().Id;
}
double indirect = 0;
double direct = 0;
10.Times(it =>
{
indirect += PerformCoreDbTest(iterations, "IndirectValue", (ctx, i) =>
{
var dbQuote = ctx.Quotes.First(x => x.Id == quote.QuoteId);
}).TotalSeconds;
direct += PerformCoreDbTest(iterations, "DirectValue", (ctx, i) =>
{
var quoteId = quote.QuoteId;
var dbQuote = ctx.Quotes.First(x => x.Id == quoteId);
}).TotalSeconds;
});
_logger.Debug($"Indirect seconds: {indirect:0.00}, direct seconds:{direct:0.00}");
}
protected TimeSpan PerformCoreDbTest(int iterations, string descriptor, Action<ICoreContext, int> testAction)
{
var sw = new Stopwatch();
sw.Start();
for (var i = 0; i < iterations; i++)
{
using (var ctx = new CoreContext())
{
testAction(ctx, i);
}
}
sw.Stop();
_logger.DebugFormat("{0}: Took {1} milliseconds for {2} iterations",
descriptor, sw.Elapsed.TotalMilliseconds, iterations);
return sw.Elapsed;
}
但我没有看到任何真正的性能优势。在两台不同的机器上，这些是 5 次迭代的结果:
Machine1 - Indirect seconds: 9.06, direct seconds:9.36
Machine1 - Indirect seconds: 9.98, direct seconds:9.84
Machine2 - Indirect seconds: 22.41, direct seconds:20.38
Machine2 - Indirect seconds: 17.27, direct seconds:16.93
Machine2 - Indirect seconds: 16.35, direct seconds:16.32
使用局部变量——MSDN 文章推荐的“直接”方法——可能是最快的一点(4/5 倍)，但不是始终如一，也不是很快。
我在测试中做错了什么吗？还是效果真的很小，没有太大区别？或者 MSDN 文章基本上是错误的，并且这种引用对象的方式对查询缓存没有任何影响？
** 编辑 10/9/16 **
我将查询修改为 (a) 使其更复杂，以及 (b) 每次传入不同的 quoteId。我怀疑后者很重要，否则查询实际上会被缓存 - 因为没有任何参数。请参阅下面来自@raderick 的答案。
这是更复杂的测试:
[Fact]
public void TestQueryCaching()
{
const int iterations = 1000;
List<EFQuote> quotes;
using (var ctx = new CoreContext())
{
quotes = ctx.Quotes.Take(iterations).ToList();
}
double indirect = 0;
double direct = 0;
double iqueryable = 0;
10.Times(it =>
{
indirect += PerformCoreDbTest(iterations, "IndirectValue", (ctx, i) =>
{
var quote = quotes[i];
var dbQuote = ctx.Quotes
.Include(x => x.QuoteGroup.QuoteGroupElements.Select(e => e.DefaultElement.DefaultChoices))
.Include(x => x.QuoteElements.Select(e => e.DefaultElement.DefaultChoices))
.Include(x => x.QuotePackage)
.Include(x => x.QuoteDefinition)
.Include(x => x.QuoteLines)
.First(x => x.Id == quote.Id);
}).TotalSeconds;
direct += PerformCoreDbTest(iterations, "DirectValue", (ctx, i) =>
{
var quoteId = quotes[i].Id;
var dbQuote = ctx.Quotes
.Include(x => x.QuoteGroup.QuoteGroupElements.Select(e => e.DefaultElement.DefaultChoices))
.Include(x => x.QuoteElements.Select(e => e.DefaultElement.DefaultChoices))
.Include(x => x.QuotePackage)
.Include(x => x.QuoteDefinition)
.Include(x => x.QuoteLines)
.First(x => x.Id == quoteId);
}).TotalSeconds;
iqueryable += PerformCoreDbTest(iterations, "IQueryable", (ctx, i) =>
{
var quoteId = quotes[i].Id;
var dbQuote = ctx.Quotes
.Include(x => x.QuoteGroup.QuoteGroupElements.Select(e => e.DefaultElement.DefaultChoices))
.Include(x => x.QuoteElements.Select(e => e.DefaultElement.DefaultChoices))
.Include(x => x.QuotePackage)
.Include(x => x.QuoteDefinition)
.Include(x => x.QuoteLines)
.Where(x => x.Id == quoteId).First();
}).TotalSeconds;
});
_logger.Debug($"Indirect seconds: {indirect:0.00}, direct seconds:{direct:0.00}, iqueryable seconds:{iqueryable:0.00}");
}
结果(超过 10,000 次总迭代)更像是上面 MSDN 文章中描述的:
Indirect seconds: 141.32, direct seconds:91.95, iqueryable seconds:93.96
最佳答案
我不是 100% 确定本文可以描述 Entity Framework 版本 6 的当前行为，但这应该与 Entity Framework 中的查询编译为存储过程有关。
当您第一次使用 Entity Framework 调用某个查询时，它必须由 EF 编译成 SQL 语句 - 要么是纯 SELECT 查询，要么是使用 exec 的过程。及其参数，例如:
exec sp_executesql N'SELECT
[Extent1].[Id] AS [Id],
[Extent1].[Name] AS [Name],
[Extent1].[IssuedAt] AS [IssuedAt],
[Extent1].[Status] AS [Status],
[Extent1].[Foo_Id] AS [Foo_Id]
FROM [dbo].[Activities] AS [Extent1]
WHERE (N''Some Name'' = [Extent1].[Name]) AND ([Extent1].[Id] = @p__linq__0)',N'@p__linq__0 int',@p__linq__0=0
@p__linq__0是查询中的一个参数，因此每次更改查询代码中的 Id 时， Entity Framework 都会从查询缓存中选择这个完全相同的语句并调用它，而不会再次尝试为其编译 SQL。另一方面N''Some Name'' = [Extent1].[Name]部分等于代码 x.Name == "Some Name" ，我在这里使用了一个常量，所以它不是转换为查询参数，而是转换为查询语句的简单部分。每次尝试进行查询时， Entity Framework 都会检查包含已编译 SQL 语句的缓存，以查看是否存在可以与参数一起重用的已编译语句。如果未找到该语句，则 Entity Framework 必须再次将 C# 查询编译为 Sql。因此，如果您的查询很小且编译速度很快，您将不会注意到任何事情，但是如果您有包含大量包含、条件、转换和内置函数使用的“难以编译”的查询，您可以点击当您的查询未命中 Entity Framework 编译的查询缓存时，将受到重罚。
您可以在此处看到与当前分页工作的一些相似之处，而不使用
Skip 的重载|和 Take , 更改页面时未命中已编译的查询缓存:Force Entity Framework to use SQL parameterization for better SQL proc cache reuse在您的代码中使用常量时，您可能会遇到这种影响，而且其影响并不明显。让我们比较这些代码片段和 EntityFramework 生成的 SQL(为了简洁，我省略了类定义，应该很明显):
查询 1
示例代码:
var result = context.Activities
.Where(x => x.IssuedAt >= DateTime.UtcNow && x.Id == iteration)
.ToList();
生成的Sql:
exec sp_executesql N'SELECT
[Extent1].[Id] AS [Id],
[Extent1].[Name] AS [Name],
[Extent1].[IssuedAt] AS [IssuedAt],
[Extent1].[Status] AS [Status],
[Extent1].[Foo_Id] AS [Foo_Id]
FROM [dbo].[Activities] AS [Extent1]
WHERE ([Extent1].[IssuedAt] >= (SysUtcDateTime())) AND ([Extent1].[Id] = @p__linq__0)',N'@p__linq__0 int',@p__linq__0=0
您可以看到在这种情况下条件
x.IssuedAt >= DateTime.UtcNow转换为语句 [Extent1].[IssuedAt] >= (SysUtcDateTime()) .查询 2
示例代码:
var now = DateTime.UtcNow;
var result = context.Activities
.Where(x => x.IssuedAt >= now && x.Id == iteration)
.ToList();
生成的Sql:
exec sp_executesql N'SELECT
[Extent1].[Id] AS [Id],
[Extent1].[Name] AS [Name],
[Extent1].[IssuedAt] AS [IssuedAt],
[Extent1].[Status] AS [Status],
[Extent1].[Foo_Id] AS [Foo_Id]
FROM [dbo].[Activities] AS [Extent1]
WHERE ([Extent1].[IssuedAt] >= @p__linq__0) AND ([Extent1].[Id] = @p__linq__1)',N'@p__linq__0 datetime2(7),@p__linq__1 int',@p__linq__0='2016-10-09 15:27:37.3798971',@p__linq__1=0
在这种情况下，您可以看到条件
x.IssuedAt >= now被转化为 [Extent1].[IssuedAt] >= @p__linq__0 - 参数化语句，DateTime 值作为过程参数传递。您可以清楚地看到这里与查询 1 的区别 - 条件是没有参数的查询代码的一部分，它使用内置函数获取日期时间。
这两个查询可能会给你一个提示， Entity Framework 中常量的使用与仅使用字段、属性、参数等产生不同的查询。这是一个合成示例，让我们检查一些更接近真实查询的内容。
查询 3
这里我使用枚举
ActivityStatus并且想要查询具有特定 ID 的事件，并且我希望能够仅获取状态为“事件”(无论这意味着什么)的事件。示例代码:
var result = context.Activities
.Where(x => x.Status == ActivityStatus.Active
&& x.Id == id)
.ToList();
生成的Sql:
exec sp_executesql N'SELECT
[Extent1].[Id] AS [Id],
[Extent1].[Name] AS [Name],
[Extent1].[IssuedAt] AS [IssuedAt],
[Extent1].[Status] AS [Status],
[Extent1].[Foo_Id] AS [Foo_Id]
FROM [dbo].[Activities] AS [Extent1]
WHERE (0 = [Extent1].[Status]) AND ([Extent1].[Id] = @p__linq__0)',N'@p__linq__0 int',@p__linq__0=0
你可以看到，在条件
x.Status == ActivityStatus.Active 中使用常量产生 SQL 0 = [Extent1].[Status] ， 哪个是正确的。此处的状态未参数化，因此如果您使用条件 x.Status = ActivityStatus.Pending 在其他地方调用相同的查询，这将产生另一个查询，因此第一次调用它会导致 Entity Framework 查询编译。您可以使用 避免它查询 4 对彼此而言。查询 4
示例代码:
var status = ActivityStatus.Active;
var result = context.Activities
.Where(x => x.Status == status
&& x.Id == iteration)
.ToList();
生成的Sql:
exec sp_executesql N'SELECT
[Extent1].[Id] AS [Id],
[Extent1].[Name] AS [Name],
[Extent1].[IssuedAt] AS [IssuedAt],
[Extent1].[Status] AS [Status],
[Extent1].[Foo_Id] AS [Foo_Id]
FROM [dbo].[Activities] AS [Extent1]
WHERE ([Extent1].[Status] = @p__linq__0) AND ([Extent1].[Id] = @p__linq__1)',N'@p__linq__0 int,@p__linq__1 int',@p__linq__0=0,@p__linq__1=0
如您所见，此查询语句已完全参数化，因此将状态更改为 Pending、Active、Inactive 等仍将使用来自已编译查询缓存的相同查询。
根据您的编码风格，您可能会不时遇到这个问题，当相同的 2 个只有不同常量值的查询将分别编译一个查询时。我可以为您提供使用 bool 值作为常量尝试相同的查询，它应该产生相同的结果 - 条件未参数化。
关于c# - Entity Framework 查询缓存，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/39927354/