参数化查询的 Dapper 性能不佳答案

【问题标题】：Bad Dapper performance for parametrized queries参数化查询的 Dapper 性能不佳
【发布时间】：2016-07-22 19:09:46
【问题描述】：

当我遇到一个奇怪的问题时，我正在研究将我们的一些 EF6 代码移植到 Dapper 以获得更好的性能。单行查询在 Dapper 中的消耗量是在 EF 中的几乎 10 倍。它看起来像这样：

using (IDbConnection conn = new SqlConnection("connection string"))
{                
      row = conn.Query<ReportView>("select * from ReportView where ID = @ID", 
                                          new {ID = id}))
                                  .FirstOrDefault();
}

此查询以大约 80 列的视图为目标，EF 版本使用相同的精确查询和相同的模型。供参考，这是 EF 版本：

row = context.ReportViews.Where(s => s.ID == id).FirstOrDefault();

我考虑到第一次查询可能会很慢，所以我在“热身”一段时间后进行了测量。我认为这可能是重用 EF 模型的问题，所以我创建了一个简单的 POCO 作为模型。这些都不起作用。所以我玩弄了它，尝试了不同的东西，并决定尝试使用 SQL 注入连接的 SQL 语句。

using (IDbConnection conn = new SqlConnection("connection string"))
{                
      row = conn.Query<ReportView>(string.Format("select * from ReportView where ID = '{0}'", 
            id)).FirstOrDefault();
}

这个查询实际上比 EF 更快。

那么这里发生了什么？为什么参数化查询这么慢？

【问题讨论】：

分析生成的 SQL
由于缺少自然键，我在使用带有 EF 的视图时遇到了各种问题。我不确定你的视图是做什么的（也许你不能在 EF 中做一些事情，比如使用 CTE），但为什么不在视图中尝试查询而不是使用 Dapper 的视图。
你的基准测试如何？
@stuartd - 如何获取生成的 SQL？
如果您使用的是 SQL Server，请使用分析器工具。我确信其他 RDBMS 也可以使用类似的工具。

标签： c# performance entity-framework dapper

【解决方案1】：

根据您的最后一个示例，您的列似乎很可能是varchar，但是当您使用参数化查询时，参数将作为nvarchar 发送。由于 nvarchar 到 varchar 可能涉及数据丢失，SQL 将表中的每个值转换为 nvarchar 以进行比较。可以想象，转换每一行进行比较的速度很慢，并且会妨碍索引的使用。

要解决此问题，您有两种选择：

如果您的数据库根本不使用 nvarchar，您只需在应用程序启动期间更改映射：

Dapper.SqlMapper.AddTypeMap(typeof(string), System.Data.DbType.AnsiString);

否则您可以根据查询更改它：

row = conn.Query<ReportView>("select * from ReportView where ID = @ID", 
                              new {ID = new DbString { Value = id, IsAnsi = true }})
                              .FirstOrDefault();

【讨论】：

【解决方案2】：

它与参数的数据类型有关。如果它与索引不匹配，那么它会强制转换每一行来比较它。将其作为字符串执行，该类型由 sql 解析器选择。

【讨论】：