必须用TRY_CAST而非CAST的场景是面对VARCHAR类型但业务应为数字或日期的脏数据列（如日志表），当存在空字符串、单位符号、字母、制表符等非法值时，CAST会报错中断查询，而TRY_CAST返回NULL且不终止执行。
直接用 TRY_CAST 替代 CAST，失败时返回 NULL 而非中断查询——这是唯一能真正“静默跳过”脏数据的原生方案。
什么时候必须用 TRY_CAST 而不是 CAST
当你面对的字段是 VARCHAR 类型但业务上应为数字或日期（比如日志表、导入表、用户输入列），且数据混有空字符串、单位符号、字母、制表符、全角空格或非法日期（如 '2023-02-30'）时，CAST 会直接报错并终止整个查询。而 TRY_CAST 是 SQL Server 2012+ 唯一能在单行表达式中安全兜底的函数，不依赖 TRY...CATCH 块，也不需要提前清洗整列。
-
CAST('abc' AS INT)→ 报错：Conversion failed when converting the varchar value 'abc' to data type int. -
TRY_CAST('abc' AS INT)→ 返回NULL，其余行照常输出 -
TRY_CAST(' 42 ' AS INT)→ 成功（自动 trim 空格）；但TRY_CAST(CHAR(9) + '42' AS INT)→NULL（制表符不被 trim）
TRY_CAST 和 TRY_CONVERT 怎么选
优先用 TRY_CAST：语义清晰、标准兼容、性能略优，适合绝大多数数值和基础类型转换（INT、DECIMAL、DATE）。只有当你需要控制格式解析（比如强制按英式/美式解析日期字符串）才用 TRY_CONVERT。
-
TRY_CAST('01-02-2024' AS DATE)→ 结果依赖当前会话的DATEFORMAT，生产环境不可控 -
TRY_CONVERT(DATE, '01-02-2024', 103)→ 明确按dd/mm/yyyy解析，失败即NULL -
TRY_CONVERT(DECIMAL(5,2), '123.456')→NULL（精度超限），而TRY_CAST('123.456' AS DECIMAL(5,2))同样失败，两者行为一致
WHERE 条件里用 TRY_CAST 的坑
别在大表的 WHERE 子句里对未索引字段反复调用 TRY_CAST(col AS INT) —— 它无法利用索引，必然触发全表扫描。更糟的是，如果该列本就该存数字，长期靠 TRY_CAST 补救，说明表设计或上游写入逻辑有问题。
- 临时查数可用：
WHERE TRY_CAST(value_str AS INT) > 100 - 高频查询应加计算列：
ALTER TABLE log_table ADD safe_int AS TRY_CAST(value_str AS INT) PERSISTED，再对该列建索引 - 或前置校验：
WHERE value_str LIKE '[0-9]%' AND LEN(value_str) ，先用 <code>LIKE快速过滤再转换
转换后还要检查精度和隐式溢出
TRY_CAST 只管“能不能转”，不管“转完放不放得下”。比如 TRY_CAST('2147483648' AS INT) 返回 NULL（超出 INT 范围），但 TRY_CAST('123.45' AS INT) 也返回 NULL（小数不能直转整型），而 TRY_CAST('123.45' AS DECIMAL(5,2)) 才成功。更隐蔽的是：把 TRY_CAST 结果赋给变量或插入列时，仍可能因目标列精度不足再次溢出。
- 插入前确认目标列类型：
NUMERIC(4,0)放不下12345，哪怕TRY_CAST成功了也会在INSERT阶段报错 - 处理小数转整型需求：先
ROUND再TRY_CAST，或直接TRY_CAST(val AS DECIMAL(10,0)) - 字符串含逗号小数点（如德语
'1.234,56'）：TRY_CAST不识别，需先REPLACE标准化
真正难的不是写对 TRY_CAST，而是你得知道原始数据里有没有 BOM 头、不可见分隔符、半全角混用，以及下游字段是否悄悄定义了比预期更窄的精度。
