SQL Server 计算列降低了简单 select 语句的性能

背景:

以前，我的公司使用用户定义的函数对存储过程的 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 次。

因此，我们咨询并决定了一个解决方案，该解决方案在 View 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 中运行。

最佳答案

添加一个计算创建一个虚拟列，仍然在运行时为选定的每一行计算。你想要的是一个计算的 持久化 列，它在插入时计算并物理存储在表中:

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

关于SQL Server 计算列降低了简单 select 语句的性能，我们在Stack Overflow上找到一个类似的问题：https://stackoverflow.com/questions/10021377/