SQL Server 计算列降低了简单选择语句的性能答案

【问题标题】：SQL Server computed column is slowing down performance on a simple select statementSQL Server 计算列降低了简单选择语句的性能
【发布时间】：2012-04-18 18:23:51
【问题描述】：

背景：

以前，我的公司使用用户定义的函数对存储过程的 where 子句中的一些数据进行 html 编码。示例如下：

DECLARE @LName --HTML encoded last name as input parameter from user

SELECT * 
  FROM (SELECT LName
          FROM SomeView xtra
         WHERE (( @LName <> '' 
              AND dbo.EncodingFunction(dbo.DecodingFunction(xtra.LName)) = @LName) 
           OR @Lname=''))

为了清楚起见，我对此进行了简化。

问题是，当这个查询的存储过程被快速连续调用 45 次时，一个有 62,000 条记录的表的平均性能大约是 85 秒。当我移除 UDF 后，性能提升到 1 秒多一点，运行 sproc 45 次。

因此，我们咨询并决定了一个解决方案，该解决方案在视图访问的表中包含一个计算列，SomeView。计算列被写入到表定义中，如下所示：

[LNameComputedColumn] AS (dbo.EncodingFunction(dbo.DecodingFunction([LName])))

然后我运行一个更新表的进程，并自动为所有 62,000 条记录填充该计算列。然后我把存储过程查询改成如下：

DECLARE @LName --HTML encoded last name as input parameter from user

SELECT * FROM
      (SELECT LNameComputedColumn
      FROM SomeView xtra
      WHERE  (( @LName <> '' AND xtra.LNameComputedColumn=@LName) OR @Lname='')

当我运行该存储过程时，45 次执行的平均运行时间增加到大约 90 秒。我的更改实际上使问题变得更糟！

我做错了什么？有没有办法提高性能？

附带说明一下，我们目前使用的是 SQL Server 2000，并计划很快升级到 2008 R2，但所有代码都必须在 SQL Server 2000 中运行。

【问题讨论】：

OR 的意义何在？因为OR @LName = '' 没有从桌子上得到任何东西。抽象太多只会浪费每个人的时间——我们无法解释我们不知道的事情。

标签： sql sql-server stored-procedures user-defined-functions calculated-columns

【解决方案1】：

问：MS SQL 计算列正在降低性能...

A：曲棍球；）

 ... where @LName <> '' ...

问：你能说“全表扫描”吗？

我并不是说你的功能并不昂贵。但是在你指责之前，你真的必须做出一个更有选择性的“where”子句......

恕我直言...

建议：

查询数据（获取所有相关的“Lname”first）
在结果上运行你的函数（只有选定的“Lnames” - 我想，不是整个视图或表格中的每一行）
李>
在您的存储过程中执行这两项操作（使用过滤器进行查询，然后进行后处理）

【讨论】：

【解决方案2】：

添加计算会创建一个虚拟列，在运行时仍会为所选的每一行计算。你想要的是一个计算的 persisted 列，它在插入时计算并物理存储在表中：

[LNameComputedColumn] 
   AS (dbo.EncodingFunction(dbo.DecodingFunction([LName]))) PERSISTED

【讨论】：