不能直接用try_convert给强类型变量赋值——sql server会在编译期报错“将null值赋给不可为null的变量”，正确做法是先用try_convert计算再判断是否为null。
TRY_CONVERT在存储过程中能直接赋值给变量吗？
不能直接用TRY_CONVERT给强类型变量赋值——SQL Server 会提前检查表达式是否可能失败，即使结果是NULL，也会在编译期报错“将 null 值赋给不可为 null 的变量”。
正确做法是先用TRY_CONVERT计算，再判断是否为NULL：
DECLARE @val VARCHAR(20) = 'abc'; DECLARE @num INT;-
SET @num = TRY_CONVERT(INT, @val);→ 编译失败 - 改用：
SELECT @num = TRY_CONVERT(INT, @val);或SET @num = TRY_CONVERT(INT, @val);在 SQL Server 2012+ 中实际可执行，但更稳妥写法是显式判断：IF TRY_CONVERT(INT, @val) IS NOT NULL SET @num = TRY_CONVERT(INT, @val);
WHERE条件里反复用TRY_CONVERT会导致全表扫描
哪怕字段上有索引，TRY_CONVERT(INT, col) 作为标量函数会阻止优化器使用索引，大表查询性能断崖下跌。
优化思路不是“少调用”，而是“提前过滤”：
- 对数字字段：先用
col LIKE '[0-9]%'或col NOT LIKE '%[^0-9]%' AND col != ''粗筛 - 对日期字段：先用
LEN(col) = 10 AND col LIKE '[0-9][0-9][0-9][0-9]-[0-9][0-9]-[0-9][0-9]'排除明显非法格式 - 再套
WHERE TRY_CONVERT(DATE, col) IS NOT NULL做最终校验
TRY_CONVERT和TRY_CAST选哪个？
优先用TRY_CAST——语义清晰、标准兼容、无额外参数干扰。只有两种情况才必须用TRY_CONVERT：
- 需要指定日期样式码（如
TRY_CONVERT(DATE, '01/02/2024', 101)强制美式解析） - 需要控制货币/数字格式（如
TRY_CONVERT(MONEY, '$1,234.56', 0)）
注意：TRY_CAST('01/02/2024' AS DATE)结果依赖当前会话的DATEFORMAT，生产环境极易出错，这类场景别省那一个函数名。
转换后赋值到目标列时仍可能溢出
TRY_CONVERT只管“能不能转”，不管“转完放不放得下”。比如TRY_CONVERT(INT, '2147483648')返回NULL（超INT上限），但TRY_CONVERT(SMALLINT, '32768')也返回NULL；而TRY_CONVERT(NUMERIC(5,2), '123.456')同样失败（小数位超限）。
真正麻烦的是隐式二次转换：
-
DECLARE @x NUMERIC(3,0); SET @x = TRY_CONVERT(INT, '1234');→ 运行时报错，因为1234塞不进NUMERIC(3,0) - 必须同步校验精度：
WHERE TRY_CONVERT(INT, col) BETWEEN -999 AND 999，或改用更大目标类型
空格自动trim，但制表符CHAR(9)、零宽空格等不可见字符会让TRY_CONVERT静默失败，清洗时记得REPLACE(REPLACE(col, CHAR(9), ''), CHAR(10), '')。
