Entity Framework 6 vs Dapper vs SQL Server 中的存储过程 vs 请求答案

【问题标题】：Entity Framework 6 vs Dapper vs stored procedure vs request in SQL ServerEntity Framework 6 vs Dapper vs SQL Server 中的存储过程 vs 请求
【发布时间】：2019-08-07 21:38:21
【问题描述】：

我的项目中长期使用带有 LINQ 和 SQL Server 的 EF。

我正在寻找一种方法来提高我对 DB 的请求的性能。我读了很多关于 Dapper 和 Procedures 的文章，它比 EF 更快。我将 Dapper 添加到项目中，我添加了程序....但是我的测试显示了奇怪的结果。 EF 和 Dapper 以及存储过程的结果几乎相同 - 没有任何好处。

首先，我检查了一个包含很多 Join 的请求。我在 Dapper 和 Procedure 和 EF 之间得到了几乎相同的结果。然后我决定用一个没有关系的简单表进行测试。

我有表格邮政编码。有43200条记录。

ZipCode table

我在 SQL Server 中使用 EF、Dapper、存储过程和请求对 1000 条记录、10000 条记录和 43200 条记录进行了测试。

小巧玲珑

string query =
            "SELECT TOP (43200) [Zip]\r\n      ,[City]\r\n      ,[State]\r\n      ,[Latitude]\r\n      ,[Longitude]\r\n      ,[TimeZone]\r\n      ,[DST]\r\n  FROM [dbo].[ZipCodes]";

using (IDbConnection connection = new SqlConnection(_connectionString))
{
    var result = connection.QueryAsync<ZipCodes>(query).Result.ToList();
    return result;
}

var zip = db.ZipCodes.AsNoTracking().Take(43200).ToList();

存储过程

ALTER PROCEDURE [dbo].[ZIPTest]
AS 
BEGIN 
    SELECT TOP (43200) 
        [Zip], [City], [State], [Latitude], [Longitude], [TimeZone], [DST] 
    FROM 
        [dbo].[ZipCodes] 
END

SQL Server 中的请求与时间

SELECT GETDATE(); 

SELECT TOP (43200) 
    [Zip], [City], [State], [Latitude], [Longitude], [TimeZone], [DST]
FROM 
    [dbo].[ZipCodes]

SELECT GETDATE();

在我使用秒表的代码中

string first = "", second = "", third="";
System.Diagnostics.Stopwatch swatch = new System.Diagnostics.Stopwatch();
swatch = new Stopwatch();
swatch.Start(); Dapper request;

然后

swatch.Stop();
first = swatch.Elapsed.ToString(@"m\:ss\.fff");
swatch = new Stopwatch();
swatch.Start();

等等

结果：（以毫秒为单位）

                       1000     10000      43200
-------------------------------------------------
EF                      107      1085       4527
Dapper                  139      1084       4036
Stored procedure        129      1089       4519
SQL query                 8        17         60

EF、Dapper 和存储过程之间的区别非常小。为什么会这样？

为什么 SQL Server 中的查询如此之快，而来自代码的请求却慢了 15-70 倍？

好还是不好？

【问题讨论】：

基准测试很难。对于初学者：这是一个发布版本吗？您是否使用了基准测试框架？还有更多...
原始 SQL 查询和存储过程缺少很多东西 - 将数据从服务器实际传输到 C# 代码所需的时间、编写和执行模型类的时间、迭代在结果集上，将原始 SQL 数据转换为 C# 类和实例 - 这是 EF 和 Dapper 都会为您处理的基本“胶水”代码。您在这里将苹果与大象进行比较 - 这不是一个非常公平和现实的比较......
我希望 SQL Server 查询执行和数据传输的成本与这些情况相同。 SQL 查询和 ORM 之间的差异反映了客户端 ORM 处理的成本。如果您使用没有对象映射的 SqlCommand/Sqldatareader，您可能会在应用代码中看到与 SQL 查询类似的性能。
也许有帮助：stackoverflow.com/a/43590624/5779732

标签： sql-server database entity-framework linq dapper

【解决方案1】：

使用 EF 出现性能问题的代码不会神奇地使用 Dapper 或 ADO + Sprocs 运行得更快。要查明性能问题的根源，您需要调查并消除性能问题的原因。

在顶层，这些性能问题源于两个核心问题。

加载的数据过多。
加载数据过于频繁。

我要注意的关键点：（作为开始，还有很多项目，但这些是最大的胜利）

延迟加载：这是从一组相关实体加载代码的地方，但这样做时，代码会在初始加载后访问这些相关实体，从而导致单独加载这些相关实体中的每一个。
- 狩猎方法：将 SQL 分析器与仅运行您的应用程序调试实例的数据库挂钩。（即本地数据库）
- 症状：在加载单个实体或集合的主查询之后看到大量“SELECT TOP (1)...”查询。
- 修复：快速修复是引入急切加载 (.Include()) 来加载这些集合。更好的解决方法是使用.Select() 来加载相关代码所需的属性。
.ToList()：随着系统的成熟，错误的.ToList() 调用可能会导致巨大的性能问题，因为开发人员遇到了一个通过调用.ToList 解决的EF 问题。通常，当开发人员尝试在 .Where() 或 .Select() 表达式中调用方法时，这些会出现。 EF 无法理解这些以传递等效的 SQL，因此添加 .ToList() 会将其转换为 Linq2Object 并且“ta-da”它可以工作！
- 狩猎方法：查找.ToList() 的实例并标记在.Select() 或.Where() 等之前找到.ToList() 的任何情况。
- 症状：删除多余的.ToList() 会导致 EF 错误。
- 修复：检查有问题的函数是否具有等效的 DbFunctions。一个常见问题是使用 DbFunctions 中的 DateTime 函数。在其他情况下，找到有问题的函数并为正在选择的预期数据创建一个视图模型，然后创建一个属性以在视图模型中运行该函数。
客户端分页 + 实体：没有适当样本数据的开发的另一个罪过。编写的查询有效地返回所有数据，而不考虑总记录数。数据在带有分页的网格中显示在客户端，这“有效”但真的很慢。当数据库中只有 200 行时它工作得很好，但现在爬了 50,000 行。（而且只会变得更糟）
- 狩猎方法：查看任何返回集合的 API/控制器方法。这些查询是使用.ToList() 还是.Skip()+.Take()？这些方法是返回实体还是视图模型？
- 症状：分页列表加载速度非常慢。加载后，切换页面很快。
- 修复：应修改来自分页控件的调用以使用服务器端分页。这意味着将排序、页面大小和页面# 信息发送到服务器调用。这样，可以使 EF 查询更有效地仅加载控件需要显示的行数。代码还应该返回仅显示显示列的搜索结果的视图模型，以及按需加载完整实体所需的键。（例如当用户单击打开记录时。）当您只需要显示少数字段时，实体可以是重量级的。
数据库索引：是否对数据库进行了监控和维护？是否有索引和索引维护？对于 SQL Server，是否正在备份数据库并使其 Tx Log 缩小？ Code First 实现充斥着这些问题，即系统在不考虑后备数据库的情况下启动。随着系统的发展，支持它的数据库不再受到关注。
- 狩猎方法：您是否有专门的 DBA 负责维护数据库并明确说明数据库的性能达到标准？
- 症状：没有对数据库进行 DBA 或审查。应用程序使用 GUID PK，例如设置为 NEWID() 或 Guid.New()，无需任何索引维护。数据库没有设置索引。事务日志 (.LDF) 比数据库文件 (.MDF) 等大 15 倍等等等等。
- 修复：聘请 DBA。如果您使用 GUID 键，请切换到 NEWSEQUENTIALID() 并建立一些计划的索引维护作业。

【讨论】：

【解决方案2】：

您在应用程序中获得的性能受许多因素影响，但从数据库中获取数据基本上可以分为 3 部分：

查询运行时间
数据传输时间
客户端处理时间

话虽如此，如果您的最高成本是数据库本身或数据传输，那么从 FE 切换到 Dapper 或简单的数据读取器是没有意义的。但是，如果您的客户端应用程序成本最高（高并发/小负载/大量连接 (linq)/多个数据集/要映射的多个列），那么从 FE 切换到 dapper 或数据读取器将是有意义的。但是，您需要了解，您将以易用性换取性能。在时间紧迫的应用程序中，这可能有意义，但在大多数现实世界的情况下，可能没有。

【讨论】：