高级性能主题

DbContext 池

DbContext 通常是一个轻型对象：创建和释放它不涉及数据库操作，而大多数应用程序都可以这样做，而不会对性能产生任何明显的影响。 但是，每个上下文实例确实设置了执行其职责所必需的各种内部服务和对象，而且在高性能场景中，持续这样做的开销可能很大。 对于这些情况，EF Core 可以将上下文实例池化：在释放上下文时，EF Core 将重置其状态并将其存储在内部池中；当下次请求新的实例时，将返回该共用实例，而不是设置新的实例。 上下文池化允许在程序启动时一次性支付上下文设置成本，而不是持续付费。

请注意，上下文池与数据库连接池正交，而后者在数据库驱动程序的较低级别进行管理。

具有依赖关系注入

使用 EF Core 的 ASP.NET Core 应用中的典型模式涉及通过 AddDbContext 将自定义 DbContext 类型注册到依赖关系注入容器。 然后，将通过控制器或 Razor Pages 中的构造函数参数获取该类型的实例。

若要启用上下文池，只需将替换 AddDbContext 为 AddDbContextPool：

builder.Services.AddDbContextPool<WeatherForecastContext>(
    o => o.UseSqlServer(builder.Configuration.GetConnectionString("WeatherForecastContext")));

AddDbContextPool 的 poolSize 参数设置池保留的最大实例数（默认为 1024）。 一旦超过 poolSize，就不会缓存新的上下文实例，EF 会回退到按需创建实例的非池行为。

没有依赖关系注入

若要使用没有依赖关系注入的上下文池，请初始化 PooledDbContextFactory 并请求上下文实例：

var options = new DbContextOptionsBuilder<PooledBloggingContext>()
    .UseSqlServer(@"Server=(localdb)\mssqllocaldb;Database=Blogging;Trusted_Connection=True;ConnectRetryCount=0")
    .Options;

var factory = new PooledDbContextFactory<PooledBloggingContext>(options);

using (var context = factory.CreateDbContext())
{
    var allPosts = context.Posts.ToList();
}

PooledDbContextFactory 构造函数的 poolSize 参数设置池保留的最大实例数（默认为 1024）。 一旦超过 poolSize，就不会缓存新的上下文实例，EF 会回退到按需创建实例的非池行为。

基准

下面是从本地运行的 SQL Server 数据库中提取单行的基准测试结果，该数据库在同一台计算机上运行，具有或不具有上下文池。 与往常一样，结果将随着行数、数据库服务器延迟和其他因素而变化。 重要的是，这测试了单线程池的性能，而实际的争用方案可能会有不同的结果，在作出任何决定之前先对平台进行基准测试。 此处提供了源代码，请根据需要将它用作自己的度量的基础。

方法	NumBlogs	平均值	错误	标准偏差	Gen 0	Gen 1	Gen 2	已分配
WithoutContextPooling	1	701.6 us	26.62 us	78.48 us	11.7188	-	-	50.38 KB
WithContextPooling	1	350.1 us	6.80 us	14.64 us	0.9766	-	-	4.63 KB

管理共用上下文中的状态

上下文池的工作原理是跨请求重用相同的上下文实例；这意味着它实际上注册为单一实例，并且同一实例在多个请求（或 DI 范围）中重复使用。 这意味着当上下文涉及可能在请求之间发生更改的任何状态时，必须特别注意。 非常重要的一点是，上下文的 OnConfiguring 仅在首次创建实例上下文时调用一次，因此不能用于设置需要更改的状态（例如租户 ID）。

涉及上下文状态的典型场景是多租户 ASP.NET Core 应用程序，其中上下文实例具有查询时考虑的租户 ID（有关更多详细信息，请参阅全局查询筛选器）。 由于租户 ID 需要随着每个 Web 请求而更改，因此我们需要执行一些额外的步骤才能使其全部适用于上下文池。

假设你的应用程序注册了一个作用域 ITenant 服务，其中包含租户 ID 和任何其他与租户相关的信息：

// Below is a minimal tenant resolution strategy, which registers a scoped ITenant service in DI.
// In this sample, we simply accept the tenant ID as a request query, which means that a client can impersonate any
// tenant. In a real application, the tenant ID would be set based on secure authentication data.
builder.Services.AddHttpContextAccessor();
builder.Services.AddScoped<ITenant>(sp =>
{
    var tenantIdString = sp.GetRequiredService<IHttpContextAccessor>().HttpContext.Request.Query["TenantId"];

    return tenantIdString != StringValues.Empty && int.TryParse(tenantIdString, out var tenantId)
        ? new Tenant(tenantId)
        : null;
});

如上所述，请特别注意从何处获取租户 ID - 这是应用程序安全性的重要方面。

拥有作用域 ITenant 服务后，照常将池上下文中心注册为单一实例服务：

builder.Services.AddPooledDbContextFactory<WeatherForecastContext>(
    o => o.UseSqlServer(builder.Configuration.GetConnectionString("WeatherForecastContext")));

接下来，编写一个自定义上下文中心，该中心从已注册的单一实例中心获取共用上下文，并将租户 ID 注入到它移交的上下文实例中：

public class WeatherForecastScopedFactory : IDbContextFactory<WeatherForecastContext>
{
    private const int DefaultTenantId = -1;

    private readonly IDbContextFactory<WeatherForecastContext> _pooledFactory;
    private readonly int _tenantId;

    public WeatherForecastScopedFactory(
        IDbContextFactory<WeatherForecastContext> pooledFactory,
        ITenant tenant)
    {
        _pooledFactory = pooledFactory;
        _tenantId = tenant?.TenantId ?? DefaultTenantId;
    }

    public WeatherForecastContext CreateDbContext()
    {
        var context = _pooledFactory.CreateDbContext();
        context.TenantId = _tenantId;
        return context;
    }
}

创建自定义上下文中心后，将其注册为作用域服务：

builder.Services.AddScoped<WeatherForecastScopedFactory>();

最后，安排从作用域中心注入上下文：

builder.Services.AddScoped(
    sp => sp.GetRequiredService<WeatherForecastScopedFactory>().CreateDbContext());

此时，控制器会自动注入具有正确租户 ID 的上下文实例，而无需了解其任何内容。

此示例的完整源代码在此处提供。

注意

尽管 EF Core 负责重置 DbContext 及其相关服务的内部状态，但它通常不会重置位于 EF 外部的基础数据库驱动程序中的状态。 例如，如果手动打开并使用 DbConnection 或以其他方式操作 ADO.NET 状态，则必须在将上下文实例返回到池之前还原该状态，例如通过关闭连接。 不执行此操作可能会导致状态在不相关的请求中泄露。

编译的查询

当 EF 收到要执行的 LINQ 查询树时，它必须首先“编译”该树，例如从其生成 SQL。 由于此任务非常繁重，EF 根据查询树形状缓存查询，因此具有相同结构的查询将重复使用内部缓存的编译输出。 此缓存可确保多次执行相同的 LINQ 查询非常快，即使参数值不同。

但是，EF 仍必须执行某些任务，然后才能使用内部查询缓存。 例如，查询的表达式树必须与缓存查询的表达式树进行递归比较，才能找到正确的缓存查询。 在大多数 EF 应用程序中，此初始处理的开销可以忽略不计，特别是与与查询执行相关的其他成本（网络 I/O、实际查询处理和数据库中的磁盘 I/O……）相比。但是，在某些高性能场景中，可能需要消除此项。

EF 支持已编译的查询，这允许将 LINQ 查询显式编译为 .NET 委托。 获取此委托后，可以直接调用它来执行查询，而无需提供 LINQ 表达式树。 此方法会绕过缓存查找，并提供在 EF Core 中执行查询的最佳方式。 下面是比较编译和非编译查询性能的一些基准测试结果：在作出任何决定之前，先对平台进行基准测试。 此处提供了源代码，请根据需要将它用作自己的度量的基础。

方法	NumBlogs	平均值	错误	标准偏差	Gen 0	已分配
WithCompiledQuery	1	564.2 us	6.75 us	5.99 us	1.9531	9 KB
WithoutCompiledQuery	1	671.6 us	12.72 us	16.54 us	2.9297	13 KB
WithCompiledQuery	10	645.3 us	10.00 us	9.35 us	2.9297	13 KB
WithoutCompiledQuery	10	709.8 us	25.20 us	73.10 us	3.9063	18 KB

要使用已编译的查询，请首先使用 EF.CompileAsyncQuery 编译查询，如下所示（使用 EF.CompileQuery 进行同步查询）：

private static readonly Func<BloggingContext, int, IAsyncEnumerable<Blog>> _compiledQuery
    = EF.CompileAsyncQuery(
        (BloggingContext context, int length) => context.Blogs.Where(b => b.Url.StartsWith("http://") && b.Url.Length == length));

在此代码示例中，我们向 EF 提供接受 DbContext 实例的 lambda，以及要传递给查询的任意参数。 现在，只要想执行查询，就可以调用该委托：

await foreach (var blog in _compiledQuery(context, 8))
{
    // Do something with the results
}

请注意，委托是线程安全的，可以在不同的上下文实例上并发调用。

限制

• 编译的查询只能用于单个 EF Core 模型。 相同类型的不同上下文实例有时可以配置为使用不同的模型；不支持在此场景中运行已编译的查询。
• 在编译的查询中使用参数时，请使用简单的标量参数。 不支持更复杂的参数表达式（例如对实例的成员/方法访问）。

查询缓存和参数化

当 EF 收到要执行的 LINQ 查询树时，它必须首先“编译”该树，例如从其生成 SQL。 由于此任务非常繁重，EF 根据查询树形状缓存查询，因此具有相同结构的查询将重复使用内部缓存的编译输出。 此缓存可确保多次执行相同的 LINQ 查询非常快，即使参数值不同。

请考虑以下两个查询：

var post1 = context.Posts.FirstOrDefault(p => p.Title == "post1");
var post2 = context.Posts.FirstOrDefault(p => p.Title == "post2");

由于表达式树包含不同的常量，因此表达式树是不同的，EF Core 将分别编译每个查询。 此外，每个查询生成一个略有不同 SQL 命令：

SELECT TOP(1) [b].[Id], [b].[Name]
FROM [Posts] AS [b]
WHERE [b].[Name] = N'post1'

SELECT TOP(1) [b].[Id], [b].[Name]
FROM [Posts] AS [b]
WHERE [b].[Name] = N'post2'

由于 SQL 不同，因此数据库服务器可能还需要为这两个查询生成查询计划，而不是重新使用同一个计划。

对查询进行少量修改可能会显著更改内容：

var postTitle = "post1";
var post1 = context.Posts.FirstOrDefault(p => p.Title == postTitle);
postTitle = "post2";
var post2 = context.Posts.FirstOrDefault(p => p.Title == postTitle);

由于博客名称现已参数化，因此两个查询具有相同的树形状，并且 EF 只需编译一次。 生成的 SQL 参数化，允许数据库重复使用相同的查询计划：

SELECT TOP(1) [b].[Id], [b].[Name]
FROM [Posts] AS [b]
WHERE [b].[Name] = @__postTitle_0

请注意，无需每个查询进行参数化：使用常量进行一些查询是非常好的，事实上，数据库（和 EF）有时可以针对常量执行某些优化，而这些优化在查询进行参数化时是不可能的。 有关适当的参数化至关重要的示例，请参阅有关动态构造查询部分。

注意

EF Core 的指标报告查询缓存命中率。 在正常的应用程序中，当大多数查询至少执行了一次后，此指标在程序启动后很快就会达到 100%。 如果此指标仍稳定在 100% 以下，则表明应用程序可能正在执行一些会破坏查询缓存的操作，建议对此进行调查。

注意

数据库如何管理缓存查询计划取决于数据库。 例如，SQL Server 隐式维护 LRU 查询计划缓存，而 PostgreSQL 不会（但已准备的语句可能会产生非常相似的结果）。 有关详细信息，请参阅数据库文档。

动态构造的查询

在某些情况下，需要动态构造 LINQ 查询，而不是在源代码中直接指定它们。 例如，这可能发生在一个网站中，该网站从客户端接收任意查询详细信息，使用开放式查询操作符（排序、筛选、分页……）。在原理上，如果正确执行，动态构造的查询可以与常规查询一样高效（尽管无法对动态查询使用编译后的查询优化）。 但是，在实践中，它们通常是性能问题的来源，因为很容易意外生成每次形状都不同的表达式树。

以下示例使用三种方法来构造查询的 Where Lambda 表达式：

1. 带常数的表达式 API：使用常数节点通过表达式 API 动态生成表达式。 这是动态生成表达式树时常见的错误，并且每次使用不同的常数值调用查询时，EF 都会重新编译查询（这通常也会导致数据库服务器上的计划缓存污染）。
2. 带参数的表达式 API：优化的版本，将常数替换为参数。 这可确保无论提供的值如何，查询仅编译一次，并生成相同的（参数化）SQL。
3. 带参数的简单版本：作为比较，不使用表达式 API 的版本，它创建与上述方法相同的树，但更简单。 在许多情况下，无需借助表达式 API 即可动态生成表达式树，但这很容易出错。

仅当给定参数不为 null 时，才会向查询添加 Where 运算符。 请注意，这不是动态构造查询的一个很好的用例，但为简单起见，我们将使用它：

带常数的表达式 API

[Benchmark]
public int ExpressionApiWithConstant()
{
    var url = "blog" + Interlocked.Increment(ref _blogNumber);
    using var context = new BloggingContext();

    IQueryable<Blog> query = context.Blogs;

    if (_addWhereClause)
    {
        var blogParam = Expression.Parameter(typeof(Blog), "b");
        var whereLambda = Expression.Lambda<Func<Blog, bool>>(
            Expression.Equal(
                Expression.MakeMemberAccess(
                    blogParam,
                    typeof(Blog).GetMember(nameof(Blog.Url)).Single()),
                Expression.Constant(url)),
            blogParam);

        query = query.Where(whereLambda);
    }

    return query.Count();
}

带参数的表达式 API

[Benchmark]
public int ExpressionApiWithParameter()
{
    var url = "blog" + Interlocked.Increment(ref _blogNumber);
    using var context = new BloggingContext();

    IQueryable<Blog> query = context.Blogs;

    if (_addWhereClause)
    {
        var blogParam = Expression.Parameter(typeof(Blog), "b");

        // This creates a lambda expression whose body is identical to the url captured closure variable in the non-dynamic query:
        // blogs.Where(b => b.Url == url)
        // This dynamically creates an expression node which EF can properly recognize and parameterize in the database query.
        // We then extract that body and use it in our dynamically-constructed query.
        Expression<Func<string>> urlParameterLambda = () => url;
        var urlParamExpression = urlParameterLambda.Body;

        var whereLambda = Expression.Lambda<Func<Blog, bool>>(
            Expression.Equal(
                Expression.MakeMemberAccess(
                    blogParam,
                    typeof(Blog).GetMember(nameof(Blog.Url)).Single()),
                urlParamExpression),
            blogParam);

        query = query.Where(whereLambda);
    }

    return query.Count();
}

带参数的简单版本

[Benchmark]
public int SimpleWithParameter()
{
    var url = "blog" + Interlocked.Increment(ref _blogNumber);

    using var context = new BloggingContext();

    IQueryable<Blog> query = context.Blogs;

    if (_addWhereClause)
    {
        Expression<Func<Blog, bool>> whereLambda = b => b.Url == url;

        query = query.Where(whereLambda);
    }

    return query.Count();
}

对这两种技术进行基准测试会得到以下结果：

方法	平均值	错误	标准偏差	第 0 代	Gen1	已分配
ExpressionApiWithConstant	1,665.8 us	56.99 us	163.5 us	15.6250	-	109.92 KB
ExpressionApiWithParameter	757.1 us	35.14 us	103.6 us	12.6953	0.9766	54.95 KB
SimpleWithParameter	760.3 us	37.99 us	112.0 us	12.6953	-	55.03 KB

即使子毫秒差看起来很小，但请记住，常数版本会持续使缓存变慢，并会导致其他查询重新编译，从而降低它们的速度，对整体性能产生一般负面影响。 强烈建议避免常数查询重新编译。

注意

除非确实需要，否则请避免使用表达式树 API 构造查询。 除了 API 的复杂性外，使用 API 时很容易在无意中导致严重的性能问题。

已编译的模型

已编译的模型可以加快具有大型模型的应用程序的 EF Core 启动时间。 大型模型通常是指数百到数千种实体类型和关系。 这里的启动时间是在应用程序中首次使用 DbContext 类型时对 DbContext 执行首次操作的时间。 请注意，仅创建 DbContext 实例不会导致初始化 EF 模型。 相反，会导致模型初始化的典型首次操作包括调用 DbContext.Add 或执行第一个查询。

使用 dotnet ef 命令行工具创建已编译的模型。 在继续之前，请确保已安装了该工具的最新版本。

新 dbcontext optimize 命令用于生成已编译的模型。 例如：

dotnet ef dbcontext optimize

--output-dir 和 --namespace 选项可用于指定将在其中生成已编译的模型的目录和命名空间。 例如：

PS C:\dotnet\efdocs\samples\core\Miscellaneous\CompiledModels> dotnet ef dbcontext optimize --output-dir MyCompiledModels --namespace MyCompiledModels
Build started...
Build succeeded.
Successfully generated a compiled model, to use it call 'options.UseModel(MyCompiledModels.BlogsContextModel.Instance)'. Run this command again when the model is modified.
PS C:\dotnet\efdocs\samples\core\Miscellaneous\CompiledModels>

• 有关详细信息，请参阅 dotnet ef dbcontext optimize。
• 如果你更习惯使用 Visual Studio，则还可使用 Optimize-DbContext

运行此命令的输出包含一段代码，可将其复制并粘贴到 DbContext 配置，以让 EF Core 使用已编译的模型。 例如：

protected override void OnConfiguring(DbContextOptionsBuilder optionsBuilder)
    => optionsBuilder
        .UseModel(MyCompiledModels.BlogsContextModel.Instance)
        .UseSqlite(@"Data Source=test.db");

编译模型启动

通常不需要查看生成的启动代码。 但有时，这样做有助于对模型或其加载方式进行自定义。 启动代码看起来如下所示：

[DbContext(typeof(BlogsContext))]
partial class BlogsContextModel : RuntimeModel
{
    private static BlogsContextModel _instance;
    public static IModel Instance
    {
        get
        {
            if (_instance == null)
            {
                _instance = new BlogsContextModel();
                _instance.Initialize();
                _instance.Customize();
            }

            return _instance;
        }
    }

    partial void Initialize();

    partial void Customize();
}

这是一个包含分部方法的分部类，可实现这些方法来根据需要自定义模型。

此外，还可根据某些运行时配置，为可能使用不同模型的 DbContext 类型生成多个编译模型。 它们应置于不同的文件夹和命名空间中，如上所示。 然后，可以检查运行时信息（如连接字符串），并根据需要返回正确的模型。 例如：

public static class RuntimeModelCache
{
    private static readonly ConcurrentDictionary<string, IModel> _runtimeModels
        = new();

    public static IModel GetOrCreateModel(string connectionString)
        => _runtimeModels.GetOrAdd(
            connectionString, cs =>
            {
                if (cs.Contains("X"))
                {
                    return BlogsContextModel1.Instance;
                }

                if (cs.Contains("Y"))
                {
                    return BlogsContextModel2.Instance;
                }

                throw new InvalidOperationException("No appropriate compiled model found.");
            });
}

限制

已编译的模型有一些限制：

• 不支持全局查询筛选器。
• 不支持延迟加载和更改跟踪代理。
• 在模型定义或配置更改时，必须重新生成模型来手动同步模型。
• 不支持自定义 IModelCacheKeyFactory 实现。 但是，可以编译多个模型，并根据需要加载相应的模型。

由于这些限制，只应在 EF Core 启动时间太慢时使用已编译的模型。 编译小型模型通常不太值得使用已编译的模型。

如果支持其中的任何功能对你的成功至关重要，那么请为上面链接的相应问题投票。

降低运行时开销

与任何层一样，EF Core 与直接针对较低级别数据库 Api 编码相比，增加了一些运行时开销。 此运行时开销不太可能会显著影响大多数实际应用程序；本性能指南中的其他主题（如查询效率、索引使用情况和最小化往返）更为重要。 此外，即使对于高度优化的应用程序，网络延迟和数据库 i/o 通常会占用 EF Core 本身的所有时间。 但是，对于高性能、低延迟的应用程序，如果每个性能都非常重要，则使用以下建议将 EF Core 开销降到最低：

• 打开 DbContext 池我们的基测试表明，此功能可能会对高性能、低延迟的应用程序产生决定性影响。
  • 请确保 maxPoolSize 符合使用场景；如果此值太低，DbContext 实例将被不断地创建和释放，从而降低性能。 如果将它设置得过高，则可能不必要地消耗内存，因为未使用的 DbContext 实例仍保留在池中。
  • 为了增加极小的性能，请考虑使用 PooledDbContextFactory 而不是让 DI 直接插入上下文实例。 对 DbContext 池的 DI 管理会产生轻微的开销。
• 使用预编译查询进行热查询。
  • LINQ 查询越复杂，它包含的运算符越多，生成的表达式树越大，使用编译查询的收益就越大。
• 请考虑在上下文配置中将 EnableThreadSafetyChecks 设置为 false 来禁用线程安全性检查。
  • 不支持从不同的线程并发地使用相同的 DbContext 实例。 EF Core 具有一项安全功能，该功能可在许多情况下（但并不是全部）检测此编程 bug，并且会立即引发信息性异常。 但是，此安全功能增加了一些运行时开销。
  • 警告：仅在全面测试应用程序不包含此类并发 bug 后禁用线程安全检查。