cast和convert转整型常报错因遇非数字字符（如'abc'、空格）直接抛异常；推荐用try_cast/try_convert返回null实现安全转换，避免运行时中断。
CAST 和 CONVERT 转整型时为什么常报错 Conversion failed when converting the varchar value 'abc' to data type int
因为 SQL Server 遇到无法解析为整数的字符串（比如空格、字母、NULL、科学计数法格式）会直接抛异常，不支持“静默失败”。CAST 和 CONVERT 都是强转换函数，没做前置校验就调用，等于把风险交给运行时。
实际场景中，原始数据常含脏值：用户输入字段、日志提取列、ETL 中未清洗的文本列。不能假设 ISNUMERIC() 就够用——它对 '1e2'、'.'、'' 都返回 1，但这些根本转不成 int。
-
ISNUMERIC('1e2')→ 1，但CAST('1e2' AS int)报错 -
ISNUMERIC('')→ 0，安全；但ISNUMERIC(' ')→ 1，而CAST(' ' AS int)报错 -
NULL可被CAST接受，结果仍是NULL，但很多业务逻辑需要区分“空”和“非法”
SQL Server 2012+ 推荐用 TRY_CAST 或 TRY_CONVERT
这两个函数在转换失败时不报错，而是返回 NULL，配合 COALESCE 或 CASE 就能实现可控降级。
它们语义清晰、行为一致，且性能接近原生 CAST（底层优化过）。优先选 TRY_CAST：语法更简洁，类型意图更明确。
-
TRY_CAST('123' AS int)→ 123 -
TRY_CAST('abc' AS int)→ NULL -
TRY_CAST(' 456 ' AS int)→ 456（自动 trim） -
TRY_CAST(NULL AS int)→ NULL -
TRY_CONVERT(int, '789')等价于上例，但写法更冗长，且不支持所有类型缩写（如int可用，tinyint必须全写）
SQL Server 2008–2008 R2 怎么安全转换？
没有 TRY_* 函数，只能靠组合判断。核心思路是：先过滤掉明显非法字符，再验证是否符合整数格式（可接受负号、无前导零、长度合理），最后才 CAST。
最简可行方案是用 LIKE 做模式匹配，比 ISNUMERIC 可靠得多：
SELECT
CASE
WHEN col LIKE '[+-][0-9]%' AND col NOT LIKE '%[^0-9+-]%' AND LEN(col)
<p>说明：</p>
-
[+-][0-9]%确保以符号或数字开头 -
NOT LIKE '%[^0-9+-]%'排除任意非数字/符号字符（注意：不允许多个符号、小数点、e、空格） LEN(col) 防止溢出（<code>int最大 2147483647，共10位；加符号最多11）- 仍需注意：该表达式不处理前导零问题（如
'00123'可转，但可能暗示数据质量差）
为什么别在 WHERE 或 JOIN 条件里直接用 CAST 转字符串列？
即使数据“看起来都合法”，SQL Server 查询优化器也可能把 CAST 下推到扫描阶段，导致索引失效，甚至在估算行数时因转换失败中断执行计划生成。
例如：WHERE CAST(str_col AS int) > 100 —— 若表中有百万行且某几行含非法值，查询可能中途报错；即使没报错，也大概率走全表扫描。
- 正确做法：先用
TRY_CAST计算列（或计算列 + 索引），再在条件中引用该列 - 若必须实时转换，至少加过滤：
WHERE str_col NOT LIKE '%[^0-9]%' AND str_col != '' AND CAST(str_col AS int) > 100，但仍有风险 - 生产环境强烈建议：在 ETL 或入库时完成清洗，字符串列不该承担数值语义
真正麻烦的不是语法怎么写，而是得想清楚：这个转换是临时取数用，还是后续要建索引、参与聚合、被其他模块复用？前者可用 TRY_CAST 快速兜底；后者必须推动源头治理——字符串字段存数字，迟早踩坑。
