我做了一个小测试,启用惰性loading.optionsBuilder.UseLazyLoadingProxies().UseSqlServer(ConnectionString);
(使用 EF Core 2.1.4)
我循环浏览有和没有的仪器,这是我得到的结果
情况1
var instruments = db.instruments.OrderBy(t=>t.id).Include(t=>t.NavPro1).ThenInclude(t=>t.NavPro2).Take(200);
Run Code Online (Sandbox Code Playgroud)
案例2
var instruments = db.instruments.OrderBy(t=>t.id).Include(t=>t.NavPro1).ThenInclude(t=>t.NavPro2).Take(200);
Run Code Online (Sandbox Code Playgroud)
然后
foreach (var i in instruments)
{
var props = i.NavPro1;
foreach (var prop in props)
{
sbPrintGreeks.AppendLine(prop.NavPro2.Name + " - " + prop.id + " - " + prop.Value);
}
}
Run Code Online (Sandbox Code Playgroud)
无需延迟加载,只需 7 秒即可获取 100k 行
使用延迟加载需要 160 秒才能获取 3k 行。
可以做些什么来获得良好的性能?
小智 4
是的,避免延迟加载。时期。
问题是 - 总是,回到曾经构建的每个 ORM - 如果你进行延迟加载,每个引用都是延迟加载。即 1 次以上往返(每个酒店至少一次)。单独的SQL执行,单独的网络时间。这加起来非常快。
这就是为什么曾经编写的每个 ORM 都支持非延迟加载,在 EF 变体中通过 .Include 语句,这些语句要么扩展 SQL,要么生成单独的 SQL(ef core、tolist 以实现与高效 sql 的关系)。
如果您坚持使用延迟加载 - 正如您的问题所暗示的那样,您不会在代码中散布魔法灰尘来避免延迟加载的隐含负面影响。
现在,补充一点 - 3.0 之前的任何 EF Core 都非常糟糕。是的,那是 3.0 - 甚至不是 2.2。看,各个部分都存在大量问题,包括非常基本的 LINQ。和性能。至少 2.2(希望在一个月内发布)应该可以解决一些问题。在那之前,请尝试使用 .Include 和 AsNoTracking - 因为 IIRC 存在一个性能错误,在加载 200k 行时也可能会影响您。
| 归档时间: |
|
| 查看次数: |
4144 次 |
| 最近记录: |