3

背景：

以前，我的公司使用用户定义的函数对存储过程的 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 时，运行 sproc 45 次的性能提高到 1 秒多一点。

因此，我们咨询并决定了一个解决方案，该解决方案在视图访问的表中包含一个计算列，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 中运行。

4

2 回答 2

8

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

[LNameComputedColumn] 
   AS (dbo.EncodingFunction(dbo.DecodingFunction([LName]))) PERSISTED
于 2012-04-05T01:30:48.707 回答
3

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

答：马曲棍球；）

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

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

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

恕我直言...

建议：

  1. 查询数据（首先获取所有相关的“Lname” ）

  2. 在结果上运行你的函数（只有选定的“Lnames”——我想，不是整个视图或表中的每一行）

  3. 在您的存储过程中执行这两项操作（使用过滤器进行查询，然后进行后处理）

于 2012-04-05T01:08:18.597 回答