TRY_CONVERT在转换失败时返回NULL而非报错，支持安全类型试探与脏数据清洗，兼容自动截断空格但拒绝非法格式，避免ISNUMERIC误判，性能上建议结合LIKE预过滤并显式指定日期样式码。
TRY_CONVERT 为什么能避免报错而不是直接失败
SQL Server 的 TRY_CONVERT 在遇到无法转换的值时返回 NULL，而不是像 CONVERT 那样抛出“从数据类型 varchar 转换为 int 失败”的错误。这让你能在 SELECT 或 WHERE 中安全地做类型试探，尤其适合清洗含混合格式的字段（比如字符串里混着数字、空格、单位、NULL 字符）。
它本质是「转换失败即 NULL」的封装逻辑，底层仍依赖类型系统规则——比如把 '123abc' 转 INT 就失败，但 ' 456 ' 可以成功（自动 trim + 转换）。
常见脏数据场景与 TRY_CONVERT 写法对比
假设有个日志表 raw_events，其中 event_value 是 VARCHAR(50)，实际存了各种东西：'100'、'N/A'、''、'78.5'、NULL、' 999 '。你想提取整数值做聚合：
- 直接用
CONVERT(INT, event_value)→ 遇到'N/A'就中断整个查询 - 用
TRY_CONVERT(INT, event_value)→ 返回NULL，不影响其他行，后续可用WHERE ... IS NOT NULL过滤 - 若想兼容小数，改用
TRY_CONVERT(DECIMAL(10,2), event_value)，它能接受'78.5'和'123'，但依然拒绝'123.456'（精度超限）或'$200'
和 ISNUMERIC() 搭配使用的坑
ISNUMERIC() 声称“可转成任意数字类型”，但实际宽松得离谱：它认为 '.'、'e'、'$'、',' 都是 numeric，结果传给 TRY_CONVERT(INT, ...) 依然失败。所以别写 WHERE ISNUMERIC(x) = 1 AND TRY_CONVERT(INT, x) IS NOT NULL —— 第一个条件基本没用，还拖慢性能。
更可靠的做法是跳过 ISNUMERIC，直接用 TRY_CONVERT 并加业务校验：
SELECT event_value, TRY_CONVERT(INT, event_value) AS safe_int FROM raw_events WHERE TRY_CONVERT(INT, event_value) BETWEEN 0 AND 1000000;
注意：这里用 BETWEEN 同时完成了非空判断和业务范围过滤，比先 IS NOT NULL 再 BETWEEN 少一次计算。
性能与隐式转换风险
TRY_CONVERT 不是零成本：每次调用都触发类型解析和错误捕获路径，大量数据下比纯字符串操作慢。如果字段大部分是合法数字，且你确定格式（如固定长度纯数字），用 LIKE '[0-9]%' 预过滤能显著提速。
另一个易忽略点：目标类型会影响结果。例如 TRY_CONVERT(DATE, '2023-02-30') 返回 NULL（无效日期），但 TRY_CONVERT(DATETIME2, '2023-02-30') 同样失败；而 TRY_CONVERT(DATE, '02/30/2023') 在 US 语言环境下也失败。区域设置（SET LANGUAGE）会影响字符串日期解析行为，生产环境务必显式指定风格，比如：
TRY_CONVERT(DATE, event_date, 120) -- ISO format 'yyyy-mm-dd hh:mi:ss'
不指定样式码时，依赖会话默认设置，不同服务器可能行为不一致。
