不能直接用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), '')。