TRY_CAST转换失败时返回NULL而非报错，适用于处理脏数据（如'2024-02-30'转DATE或'abc'转INT），避免查询中断；必须显式指定完整类型，仅支持SQL Server 2012+，不兜底所有格式，后续需主动处理NULL。
TRY_CAST 转换失败时返回 NULL 而不是报错
当你不确定字段值是否符合目标类型（比如把字符串 '2024-02-30' 转成 DATE，或 'abc' 转成 INT），直接用 CAST 会中断查询并抛出错误；TRY_CAST 则安静地返回 NULL，让查询继续执行。这是它最核心的价值——把“硬失败”变成“软处理”。
常见错误现象：Msg 241, Level 16, State 1: Conversion failed when converting date and/or time from character string. —— 这类错误在清洗脏数据或对接外部系统时高频出现，TRY_CAST 是第一道防线。
-
TRY_CAST('2024-02-30' AS DATE)→NULL（非法日期） -
TRY_CAST('123' AS INT)→123（成功） -
TRY_CAST('123.45' AS INT)→NULL（小数不能隐式截断转整型）
必须显式指定目标类型，且不支持所有类型组合
TRY_CAST 不是万能胶水，SQL Server 对可转换的类型对做了限制。比如 TRY_CAST('true' AS BIT) 在某些版本中不被支持（需用 TRY_CONVERT 或先标准化字符串），而 TRY_CAST(NULL AS VARCHAR(10)) 合法但无实际意义。
使用场景：常用于 WHERE 子句过滤、SELECT 中生成新列、或配合 IS NULL/IS NOT NULL 判断转换结果。
- 只支持 SQL Server 2012+ 和 Azure SQL；旧版本只能用
TRY_CONVERT替代（行为类似但函数名不同） -
TRY_CAST('123' AS DECIMAL(5,2))→123.00，但TRY_CAST('123.456' AS DECIMAL(5,2))→NULL（精度溢出） - 不能跳过类型声明：
TRY_CAST('123')语法错误，必须写全AS xxx
和 ISNUMERIC() 配合使用容易踩坑
ISNUMERIC('1e4') 返回 1，但 TRY_CAST('1e4' AS INT) 仍会失败（科学计数法不被 INT 接受）；ISNUMERIC('') 也返回 1，但 TRY_CAST('' AS INT) 是 NULL。所以别依赖 ISNUMERIC() 做前置判断。
更稳妥的做法是直接用 TRY_CAST 并检查结果：
SELECT
input_value,
TRY_CAST(input_value AS INT) AS safe_int,
CASE WHEN TRY_CAST(input_value AS INT) IS NOT NULL THEN 'valid' ELSE 'invalid' END AS status
FROM (VALUES ('123'), ('abc'), (''), ('1e4')) t(input_value);
-
ISNUMERIC()判定范围比实际可CAST的宽，它只是“看起来像数字”，不是“能转成某类型” - 如果业务要求严格数值校验（如整数、无前导零、非负），仍需额外
LIKE或正则（SQL Server 2016+ 支持STRING_SPLIT+ 模式匹配）
性能影响小，但嵌套多层 TRY_CAST 会拖慢查询
单次 TRY_CAST 开销几乎可忽略，它本质是轻量级异常屏蔽，不触发完整错误处理栈。但若在大表上对每行做多次嵌套尝试（比如 TRY_CAST(TRY_CAST(col AS VARCHAR) AS INT)），不仅逻辑混乱，还会因重复解析增加 CPU 压力。
- 优先在
WHERE中提前过滤掉明显非法值（如col NOT LIKE '%[^0-9]%' AND col != ''），减少TRY_CAST调用次数 - 避免在索引列上直接用
TRY_CAST做等值查找（如WHERE TRY_CAST(id_str AS INT) = 123），会导致索引失效 - 如果转换逻辑复杂且高频，考虑用计算列 + 索引固化结果，而不是每次查都算
实际用的时候，多数人卡在“以为 TRY_CAST 能兜住所有格式”，结果发现空字符串、带空格、科学计数法、Unicode 符号这些边界情况还是得手动清理。容错不是免检，而是把报错变成可控的 NULL，后续怎么处理这个 NULL，才是关键。
