Entity Framework Core 首次查询与后续查询性能

Question

最近我一直在想，实体框架中第一次查询和后续相同查询性能之间的巨大差异背后的原因是什么？ 是不是因为 Entity Framework 有某种内部缓存来缓存查询结果，并且对同一查询的所有后续调用都使用缓存的结果？

为了正确理解这个问题，下面是我到目前为止进行的一些测试

for (var i = 0; i < 20; i++)
{
    var sw = Stopwatch.StartNew();

    var departments = _sampleContext.Departments.AsNoTracking().ToList();

    sw.Stop();

    Console.WriteLine($"Run {i+1} took {sw.ElapsedMilliseconds} ms");
}

Output：

Run 1 took 2708 ms
Run 2 took 350 ms
Run 3 took 421 ms
Run 4 took 300 ms
Run 5 took 329 ms
Run 6 took 319 ms
Run 7 took 301 ms
Run 8 took 303 ms
Run 9 took 310 ms
Run 10 took 342 ms
Run 11 took 284 ms
Run 12 took 322 ms
Run 13 took 359 ms
Run 14 took 297 ms
Run 15 took 291 ms
Run 16 took 288 ms
Run 17 took 268 ms
Run 18 took 309 ms
Run 19 took 299 ms
Run 20 took 298 ms

在这里您可以看到第一次和第二次运行之间存在巨大差异。

这背后的原因可能是什么？

除此之外，我还尝试在不使用实体框架的情况下复制相同的场景，如下所示

var sqlConnection = new SqlConnection(_configuration.GetSection("ConnectionStrings:DefaultConnection").Value);

sqlConnection.Open();

for (var i = 0; i < 20; i++)
{
    var sw = Stopwatch.StartNew();

    var sqlCommand = new SqlCommand("select * from Departments", sqlConnection);

    using var sqlDataReader = sqlCommand.ExecuteReader();

    if (sqlDataReader.HasRows)
    {
        while (sqlDataReader.Read())
        {
            var id = sqlDataReader.GetInt32(0);
            var name = sqlDataReader.GetString(1);
        }
    }

    sw.Stop();

    Console.WriteLine($"Run {i + 1} took {sw.ElapsedMilliseconds} ms");
}

Output：

Run 1 took 499 ms
Run 2 took 300 ms
Run 3 took 276 ms
Run 4 took 275 ms
Run 5 took 273 ms
Run 6 took 256 ms
Run 7 took 288 ms
Run 8 took 309 ms
Run 9 took 285 ms
Run 10 took 280 ms
Run 11 took 292 ms
Run 12 took 308 ms
Run 13 took 283 ms
Run 14 took 267 ms
Run 15 took 290 ms
Run 16 took 276 ms
Run 17 took 277 ms
Run 18 took 286 ms
Run 19 took 283 ms
Run 20 took 273 ms

这里也有第一次和第二次运行之间的差异，但它不像 Entity Framework 那样剧烈。

我正在使用 EF Core 3.1

根据@Larnu 的评论，可能是因为 SQL 服务器的查询计划缓存，所以我尝试在每次迭代中运行略有不同的查询，如下所示

ADO.NET版

var sqlCommand = new SqlCommand($"select * from Departments where ID > {i}", sqlConnection);

Output：

Run 1 took 494 ms
Run 2 took 274 ms
Run 3 took 304 ms
Run 4 took 276 ms
Run 5 took 731 ms
Run 6 took 475 ms
Run 7 took 576 ms
Run 8 took 276 ms
Run 9 took 275 ms
Run 10 took 291 ms
Run 11 took 271 ms
Run 12 took 253 ms
Run 13 took 269 ms
Run 14 took 262 ms
Run 15 took 270 ms
Run 16 took 303 ms
Run 17 took 261 ms
Run 18 took 296 ms
Run 19 took 275 ms
Run 20 took 661 ms

实体框架版本：

var departments = _sampleContext.Departments.Where(x=>x.ID > i).AsNoTracking().ToList();

Output：

Run 1 took 2377 ms
Run 2 took 274 ms
Run 3 took 272 ms
Run 4 took 260 ms
Run 5 took 276 ms
Run 6 took 281 ms
Run 7 took 319 ms
Run 8 took 506 ms
Run 9 took 318 ms
Run 10 took 265 ms
Run 11 took 269 ms
Run 12 took 276 ms
Run 13 took 283 ms
Run 14 took 256 ms
Run 15 took 253 ms
Run 16 took 258 ms
Run 17 took 277 ms
Run 18 took 298 ms

我想第一次和第二次查询之间的差异仍然非常大，这仅仅是因为 SQL 服务器的查询计划缓存还是其他原因？

Answer 1

我认为这会回答你的问题： https://github.com/do.net/efcore/issues/9347

长话短说，model 在第一次运行时构建上下文需要时间。 model 越大，花费的时间就越多。

您可以发现以下发现：

第一次查询的总毫秒数 126078

第二次查询的总毫秒数 17

首次保存的总毫秒数 121

每秒节省的总毫秒数 10

该团队知道第一个查询中的 model 构建需要时间，他们已经稍微减轻了它，但正如评论中提到的那样：

我们已经稍微改进了 model 建筑性能，但您最好的选择是等待编译模型 #1906