将VARCHAR转换为INT：TRY_CAST与TRY/CATCH哪种方案更优？

我正在处理SQL Server 2019环境下的一段T-SQL代码，存储过程有一个重载的VARCHAR(15)类型参数，后续需要转换为INT。考虑到转换可能失败的场景——比如参数不是数字字符串，或者数值超出INT的范围——我在纠结两种实现方式：用TRY_CAST替代CAST，还是用TRY/CATCH块处理转换成功或异常退出。

示例代码如下：

-- 初始化变量
DECLARE @AParamter varchar(15) = '214748364700'; -- 数值是INT最大值的100倍
DECLARE @AVariable int;

-- 方案1：使用TRY_CAST
SET @AVariable = TRY_CAST(@AParamter AS int);

IF (@AVariable IS NULL) BEGIN
    PRINT 'ERROR: invalid parameter';
END

-- 方案2：使用TRY/CATCH块
BEGIN TRY
    SET @AVariable = CAST(@AParamter AS int);
END TRY
BEGIN CATCH
    PRINT 'ERROR: invalid parameter';
END CATCH

两种方法都能实现需求，但我想知道哪种性能更高（占用更少资源），以及各自是否存在潜在隐患。我尝试用sys.dm_exec_*_stats视图收集存储过程指标，重点关注Total_Worker_Time和Total_Elapsed_Time，但这些指标波动较大，没法准确判断两种方案的实际影响。

另外，我个人更倾向于不使用重载参数，而是用多个类型正确的参数、每次仅一个非空，并通过检查确保唯一有效值，但这个方案不由我决定。

性能对比 #

从性能角度看，TRY_CAST是更优选择：

• TRY_CAST是SQL Server原生的轻量级转换函数，转换失败时仅返回NULL，不会触发完整的异常捕获流程。而TRY/CATCH块在捕获异常时，需要生成异常堆栈、填充系统错误信息（如ERROR_NUMBER()、ERROR_MESSAGE()等），会带来额外资源开销——尤其是在转换失败场景较多的情况下，性能差异会更明显。
• 即使转换成功，TRY_CAST的执行开销也略低于CAST+TRY/CATCH，因为后者会引入异常处理框架的初始化逻辑。

潜在隐患 #

方案1（TRY_CAST）的注意点 #

• 若参数本身是NULL，TRY_CAST也会返回NULL，需要额外区分“参数为NULL”和“转换失败”两种场景，如果业务需要不同处理，需增加非空检查：

  IF @AParamter IS NULL BEGIN
      PRINT 'ERROR: parameter cannot be null';
  END ELSE BEGIN
      SET @AVariable = TRY_CAST(@AParamter AS int);
      IF @AVariable IS NULL BEGIN
          PRINT 'ERROR: invalid parameter';
      END
  END
  

• TRY_CAST会忽略参数前后的空格（比如' 123 '会成功转换为123），如果业务不允许这种情况，需先执行LTRIM(RTRIM(@AParamter))，或结合PATINDEX做严格校验（ISNUMERIC()有局限性，会将'$123'这类字符串识别为有效数字）。

方案2（TRY/CATCH）的注意点 #

• TRY/CATCH会捕获所有异常，不止是转换失败——比如变量误写为只读、语法错误等情况也会进入CATCH块，导致错误信息不够精准。如需区分具体异常类型，需在CATCH块中判断ERROR_NUMBER()：

  BEGIN CATCH
      IF ERROR_NUMBER() IN (245, 8114) BEGIN -- 245为转换失败，8114为数据类型转换错误
          PRINT 'ERROR: invalid parameter';
      END ELSE BEGIN
          -- 抛出其他未处理异常
          THROW;
      END
  END CATCH
  

• 异常捕获会中断TRY块内的后续执行逻辑，若TRY块中有多步操作，需注意异常发生后的流程中断问题。

最佳实践与替代方案 #

1. 优先选用TRY_CAST：大多数场景下它更高效、代码更简洁，能满足基本的转换失败处理需求。
2. 增强参数校验逻辑：如果需要更严格的参数验证（比如确保是纯数字字符串），可以结合PATINDEX实现：

   IF @AParamter IS NULL OR PATINDEX('%[^0-9]%', @AParamter) > 0 BEGIN
       PRINT 'ERROR: parameter must be a numeric string';
   END ELSE BEGIN
       SET @AVariable = TRY_CAST(@AParamter AS int);
       IF @AVariable IS NULL BEGIN
           PRINT 'ERROR: parameter exceeds INT range';
       END
   END
   

3. 重载参数的分层处理：虽然无法决定外部参数设计，但可以在存储过程内部先完成参数类型转换与校验，再调用内部的类型正确的存储过程或业务逻辑，实现参数校验与业务逻辑的分离，提升代码可维护性。

内容的提问来源于stack exchange，提问作者Russ Perry Jr