try_cast在sql server 2012+中转换失败时返回null而非报错，适用于脏数据容错转换；但不修复值、不提示错误，需显式处理null，且不支持mysql/postgresql。
TRY_CAST 在 SQL Server 中的实际行为
TRY_CAST 不会报错，转换失败时直接返回 NULL，这是它和 CAST 的核心区别。但要注意：它只在 SQL Server 2012+ 和 Azure SQL 中可用，MySQL、PostgreSQL 不支持该函数（对应的是 CAST(... AS ...) 加异常捕获或 SAFE_CAST 等替代方案）。
常见误用是以为 TRY_CAST 能“静默修复”非法值——其实它只是跳过，不修正也不提示。比如把 'abc' 转成 INT，结果是 NULL，不是 0 或默认值。
怎么写才不会漏掉 NULL 导致逻辑错误
TRY_CAST 返回 NULL 是“合法结果”，不是“异常信号”。如果后续逻辑没处理 NULL，可能引发空值传播（比如聚合时被忽略、JOIN 时丢失匹配、WHERE 条件意外跳过）。
- 显式检查是否转换成功：
WHERE TRY_CAST(value AS INT) IS NOT NULL - 需要默认值时用
ISNULL(TRY_CAST(value AS INT), 0)，但注意 0 可能和真实数据冲突（比如原始字段本就含 0） - 调试阶段建议先查出所有转换失败的原始值：
SELECT value FROM table WHERE TRY_CAST(value AS DECIMAL(10,2)) IS NULL AND value IS NOT NULL
和 CASE + ISNUMERIC 配合使用的典型陷阱
有人习惯先用 ISNUMERIC() 判断再 TRY_CAST，但 ISNUMERIC('1e4') 返回 1，TRY_CAST('1e4' AS INT) 却失败（因为 INT 不接受科学计数法）。同理，ISNUMERIC('$123') 也返回 1，但无法转成数字类型。
更可靠的做法是：直接 TRY_CAST 并验证结果，而不是依赖前置判断。例如：
SELECT
value,
TRY_CAST(value AS DECIMAL(10,2)) AS safe_decimal,
CASE
WHEN TRY_CAST(value AS DECIMAL(10,2)) IS NULL THEN 'invalid'
ELSE 'valid'
END AS status
FROM (VALUES ('123.45'), ('abc'), ('$123'), ('1e4')) t(value)
这样避免了 ISNUMERIC 的宽泛判定带来的误信。
性能影响与索引失效风险
TRY_CAST 是标量函数，出现在 WHERE 或 JOIN 条件中会导致索引无法有效使用（除非是计算列+索引的特殊情况）。如果表很大且频繁按转换后值过滤，不要写成 WHERE TRY_CAST(col AS DATE) = '2024-01-01'。
- 优先清洗数据：把可信格式提前转存到新列并建索引
- 若必须运行时转换，考虑用
LIKE或正则（SQL Server 2017+ 支持STRING_SPLIT和模式匹配）粗筛，再用 TRY_CAST 精筛 - 注意隐式转换干扰：比如
WHERE TRY_CAST(col AS INT) = '123'会让右侧字符串触发额外转换，应统一为数值比较
真正麻烦的不是 TRY_CAST 本身，而是它掩盖了数据质量差的问题——你得决定是跳过坏数据，还是停下来修数据。
