try_cast在sql server 2012+中可避免转换失败报错，失败时返回null而非中断查询；适用于脏数据场景，但需显式处理null、注意类型精度、避免where中直接使用导致索引失效。
SQL Server 中用 TRY_CAST 避免 CONVERT/CAST 报错
直接用 CAST 或 CONVERT 转数值，遇到非法字符串（如 'abc'、NULL、空格）会直接中断执行——这不是“异常可捕获”，而是语句级硬错误，TRY...CATCH 都拦不住。
正确做法是改用 TRY_CAST（SQL Server 2012+）或 TRY_CONVERT：
-
TRY_CAST('123' AS INT)→ 返回123 -
TRY_CAST('xyz' AS INT)→ 返回NULL，不报错 -
TRY_CAST(NULL AS DECIMAL(10,2))→ 返回NULL，安全
它本质是“失败静默返回 NULL”，后续逻辑必须显式判断结果是否为 NULL，不能默认认为转换成功。
MySQL 存储过程中用 DECLARE HANDLER 捕获数值转换错误
MySQL 没有 TRY_CAST，数值转换（如 CAST('abc' AS SIGNED)）会触发 SQLSTATE '22018'（invalid character value for cast），必须靠异常处理器兜底。
关键点：
- 先用
DECLARE CONTINUE HANDLER FOR SQLSTATE '22018'捕获 - handler 内必须重置变量（如设
out_value := NULL），否则原值残留导致逻辑错乱 - 不能只声明 handler，还要在转换前清空诊断区：
GET DIAGNOSTICS CONDITION 1 @sqlstate = RETURNED_SQLSTATE;避免旧错误干扰
示例片段：
DECLARE CONTINUE HANDLER FOR SQLSTATE '22018' BEGIN SET out_num = NULL; SET error_msg = '数值格式非法'; END;
Oracle PL/SQL 里别依赖隐式转换，显式用 TO_NUMBER 并配异常块
Oracle 对字符串转数字极其严格，TO_NUMBER(' 123 ') 可以，但 TO_NUMBER('123abc') 或含不可见字符（如 CHR(0)）会抛 VALUE_ERROR 异常。
必须写完整异常处理：
- 预定义异常
VALUE_ERROR必须出现在EXCEPTION块中，不能只靠WHEN OTHERS - 若需记录具体错误位置，用
SQLCODE和SQLERRM，例如：DBMS_OUTPUT.PUT_LINE('Error ' || SQLCODE || ': ' || SQLERRM); - 避免在循环内反复调用
TO_NUMBER却不重置变量——上一次失败后变量仍为旧值，下一次可能误用
跨数据库兼容写法：先校验再转换
如果存储过程要跑在多个数据库（如 SQL Server + PostgreSQL + MySQL），别指望统一函数，最稳的方式是“校验先行”：
- 用正则或字符串函数判断是否纯数字：
WHERE col REGEXP '^-?[0-9]+\.?[0-9]*$'（MySQL）、col ~ '^[-+]?[0-9]*\.?[0-9]+$'（PostgreSQL） - 对疑似数值字段，先
TRIM()去空格，再检查长度和字符集（比如排除全角数字、中文逗号） - 校验通过后再走
CAST或对应数据库的转换函数，失败概率大幅下降
真正麻烦的不是转换本身，而是错误发生时你根本不知道原始字符串长什么样——日志里没存原始值，就只能靠猜。
