SQL Server执行UPDATE前校验变更数据的性能收益探讨

在你当前描述的场景下（75%_{80%的调用都是数据无变更的重复webhook触发，仅20%}25%请求存在实际数据修改），提前校验新旧值一致性、跳过无变化UPDATE的方案能带来非常明显的性能收益，但你当前给出的存储过程实现有几处可以优化的问题，调整后收益会更高。

方案收益的核心逻辑 #

很多人误以为SQL Server执行UPDATE时会自动判断新旧值是否一致、一致就跳过操作，实际上不管是本地SQL Server还是Azure SQL，都没有这个默认行为：

• 哪怕你SET的新值和列内存储的旧值完全相同，执行UPDATE时依然会申请更新锁、生成对应事务日志、将关联数据页标记为脏页、触发索引维护逻辑；如果表上配置了触发器、CDC、变更跟踪（Change Tracking），还会额外生成对应的变更记录，这些开销在高频调用场景下非常可观。
• 你的场景里绝大多数请求都是无变更的重复触发，跳过这些无意义UPDATE省下的日志写入、磁盘IO、锁占用、索引/附属组件维护成本，远大于提前读取一次当前行数据带来的开销，整体投入产出比很高。

当前实现的优化建议 #

你现在写的逻辑核心思路是对的，但有几个点会额外损耗性能，甚至带来并发问题：

• 不要用SERIALIZABLE隔离级别：这个隔离级别会持有范围锁直到事务结束，高并发下很容易引发阻塞甚至死锁。你已经在SELECT语句上加了UPDLOCK提示，只需要把隔离级别降到默认的READ COMMITTED就足够保证一致性：UPDLOCK会在读取目标行时直接加更新锁，阻止其他会话同时修改该行，完全避免“读值后到更新前数据被第三方修改”的竞态问题，锁粒度更细，并发性能好很多。
• 简化新旧值对比逻辑：你现在逐列写的NULL相等判断冗余且容易写错，Azure SQL已经支持IS NOT DISTINCT FROM语法，或者直接用EXCEPT做行值对比，不需要单独处理NULL值的等价判断，示例代码如下：

-- 直接判断当前行值和入参是否存在差异，不需要逐列写NULL判断
IF EXISTS (
    SELECT @CurrentCustomerDisplayName, @CurrentCancelledAt, @CurrentCustomerId, @CurrentTrackingNo, @CurrentTags, @CurrentToCountryCode
    EXCEPT
    SELECT @customerDisplayName, @cancelledAt, @customerId, @trackingNo, @tags, @toCountryCode
)
BEGIN
    -- 值存在差异，执行UPDATE
END
ELSE
BEGIN
    -- 值完全一致，直接跳过
END

• 可以省略单独的变量赋值步骤：不需要先把所有列的值SELECT到本地变量再做对比，可以直接通过一次查询同时完成“行是否存在”“值是否一致”的判断，进一步减少变量赋值的开销。
• 如果你后续调整了业务场景，出现90%以上的请求都存在实际数据变更的情况，这个提前校验的逻辑反而会增加额外的查询开销，到时候可以移除校验直接执行UPDATE；但按你当前的更新比例，保留校验逻辑的收益远大于成本。

注意事项 #

不要为了省开销去掉SELECT上的UPDLOCK提示：如果不加更新锁直接以普通读的方式拉取当前值做对比，会出现竞态问题——两个会话同时读到旧值，都认为数据无变化/需要更新，可能引发更新丢失、死锁等问题，你现在加UPDLOCK的思路是完全正确的，只需要调整隔离级别即可。

内容的提问来源于stack exchange，提问作者David0101