SQL Where 子句反对 View

Question

我有一个观点(实际上，它是一个表值函数，但观察到的行为在两者中是相同的)内部联接和左外部联接几个其他表。当我使用类似于

的 where 子句查询此 View 时

SELECT *
FROM [v_MyView]
WHERE [Name] like '%Doe, John%'

...查询非常慢，但如果我执行以下操作...

SELECT *
FROM [v_MyView]
WHERE [ID] in 
(
    SELECT [ID]
    FROM [v_MyView]
    WHERE [Name] like '%Doe, John%'
)

它要快得多。第一个查询至少需要 2 分钟才能返回，如果时间不长，第二个查询将在不到 5 秒内返回。

关于如何改进它有什么建议吗？如果我将整个命令作为一个 SQL 语句运行(不使用 View )，它也非常快。我相信这个结果是因为 View 应该如何表现得像一个表，如果 View 有 OUTER JOINS、GROUP BYS 或 TOP ##，如果 where 子句在 View 执行之前 vs 之后被解释，结果可能不同。我的问题是，为什么 SQL 不将我的第一个查询优化为与第二个查询一样高效的查询？

编辑

所以，我正在努力想出一个例子，并打算使用普遍可用的 AdventureWorks 数据库作为主干。在复制我的情况时(这实际上是在调试别人开发的一个缓慢的过程，不是吗？)我无法得到相同的结果。进一步查看我正在调试的查询，我意识到这个问题可能与用户定义的标量值函数的广泛使用有关。大量使用“GetDisplayName”函数，根据您传入的值，它将格式化 lastname、firstname 或 firstname lastname 等。如果我只是省略该函数并在主查询/TVF/view 中进行字符串格式化或不管怎样，性能都很棒。在查看执行计划时，它并没有给我将其视为问题的线索，这就是我最初忽略它的原因。

Answer 1

标量 UDF 很可能是问题所在。一旦他们进入您的查询，您就有了一个 RBAR 执行计划。如果它们在 SELECT 中是可以容忍的，但如果它们在 WHERE 或 JOIN 子句中使用......

很遗憾，因为它们可能非常有用，但在大型 SELECT 中它们是性能 killer ，我建议尝试将 UDF 重写为表值或查询以避免 UDF，如果可能的话。