为什么当参数作为参数传递时 sp_executesql 运行速度变慢

查询1：（快如闪电）

sp_executesql "select * from tablesView where Id = 1"

vs.

查询2：（太慢）

sp_executesql "select * from tablesView where Id = @Id", N"@Id int", @Id=1

tablesView - a view containing multiple joins

LINQ 总是将查询转换为 Query2 形式，因此性能非常糟糕。

问题：我需要 query2 缓慢的原因，以及任何解决方案（如果有）。 以及 LINQ 的解决方案。

- - 补充评论：

性能受到影响肯定是因为使用排名函数（row_number）的两列，但我无法避免它们，我需要它们。

我将在这里冒险并假设您有很多 ID = 1 的行。

如果不是，请纠正我。

SQL Server 处理查询速度缓慢的一个可能原因是它查看查询并执行以下操作：

嗯，我想知道他会为该参数传递什么。
会是1吗？我在哪里有大约无数行？
或者也许是 1742 年，那时我只有 3 个
我只是不知道，我最好进行表扫描，以确保生成一个涵盖我所有基础的执行计划

如果列或列集的选择性较低（即唯一值的数量远小于行数），SQL Server 有时会恢复到表扫描或类似操作，只是为了确定性地获取所有行。

至少这是我的经验。特别是，在对具有时间限制的数据的表进行日期范围选择时，我看到了相同的行为，执行WHERE dt <= @dt AND dt >= @dt获取 @dt 在该行的一段时间内的所有行，恢复到表扫描，然后当我将实际日期作为文字放入 SQL 中时，它运行得更快。

这里的问题是选择性，SQL Server 在为语句构建执行计划时不知道如何最好地满足所有场景，因此它会尝试猜测。

尝试添加查询提示来指定typical参数值，即：

sp_executesql "select * from tablesView where Id = @Id option (optimize for (@id = 1742))", N"@Id int", @Id=1