Sql server 根据参数有选择地更新列时存储过程的性能？

我试图弄清楚这是否是性能相对较好的T-SQL（这是SQLServer2008）。我需要创建一个更新表的存储过程。proc接受的参数与表中的列一样多，除PK列外，它们都默认为NULL。该过程的主体如下所示：

CREATE PROCEDURE proc_repo_update 
    @object_id bigint
    ,@object_name varchar(50) = NULL
    ,@object_type char(2) = NULL
    ,@object_weight int = NULL
    ,@owner_id int = NULL
    -- ...etc
AS
BEGIN
    update
        object_repo
    set
        object_name = ISNULL(@object_name, object_name)
        ,object_type = ISNULL(@object_type, object_type)
        ,object_weight = ISNULL(@object_weight, object_weight)
        ,owner_id = ISNULL(@owner_id, owner_id)
        -- ...etc
    where
        object_id = @object_id

    return @@ROWCOUNT

END

所以基本上：

仅当提供了列的相应参数时才更新该列，其余的就不用管了。

---

这已经足够好了，但是如果接收到的参数为null，那么

ISNULL

调用将返回列的值，SQL Server会以某种方式对此进行优化吗？这可能是应用程序上的一个性能瓶颈，在应用程序中，表可能会被大量更新（插入将不常见，因此那里的性能不会出现问题）。所以我想找出最好的方法。有没有一种方法可以在列表达式中设置类似于

CASE WHEN

之类的条件？为了提高读取性能，表也将在wazoo上建立索引。这是最好的方法吗？此时，我的替代方法是在代码中创建

UPDATE

表达式（例如内联SQL），并在服务器上执行它。这将解决我对性能的疑问，但如果可能的话，我宁愿将其保留在存储过程中。

ISNULL是最快的方法-唯一可以改进的方法是传入NULL或实际值，并在应用程序中执行ISNULL。

请查看Hugo Kornelis的博客文章。把关于COALESCE和ISNULL的讨论放低一点。如果可移植性是未来的一个考虑因素，那么看看COALESCE

然而，从性能的角度来看，看看Adam在的以性能为中心的博客文章。ISNULL是更快的

你的选择

---

顺便说一句，我有一堆SP，它们与您的示例一样，使用ISNULL没有性能问题。（有点懒，我喜欢键入6个字符而不是8个字符，而且有点容易出现手指阅读障碍，ISNULL更容易键入：-）

我知道这是存储过程上下文中最快的方法，但与在代码中生成UPDATE语句相比，它会慢吗？换句话说，所有这些ISNULL语句都是性能问题吗？我最好只使用内联SQL？这种技术应该不会有性能问题，但要小心，确保每次都更新每一列（即使您将其设置为等于自身）在触发器、更改数据捕获等方面没有任何意外的副作用。谢谢，我来看看这些。