ISNUMERIC返回1不保证能成功转换，因其仅判断是否符合SQL Server宽泛的数值格式（如'1e4'、'+'、'$100'均返回1），而CAST/CONVERT要求严格匹配目标类型；推荐用TRY_CAST或TRY_CONVERT替代，直接尝试转换并返回NULL而非报错。
ISNUMERIC在SQL Server中返回真值但实际转不了数值？
ISNUMERIC不是“能否安全转成数字”的可靠判断，它只检查字符串是否符合SQL Server内部的数值格式定义——比如'1e3'、'+'、'.'、'$100'都会返回1，但用CAST或CONVERT转时大概率失败。
- 真正想做类型安全转换，优先用
TRY_CAST()或TRY_CONVERT()（SQL Server 2012+） -
ISNUMERIC适合做粗筛，比如排除明显含字母的字段，但不能替代转换验证 - 注意：空字符串
''、单个'-'、'+'都返回1，却无法被CAST(... AS INT)接受
用TRY_CAST代替ISNUMERIC做安全转换
直接尝试转换并捕获失败，比先查再转更简洁、更准确。返回NULL表示不可转，不会报错。
SELECT col, TRY_CAST(col AS INT) AS int_val, TRY_CAST(col AS DECIMAL(10,2)) AS dec_val FROM your_table;
- 如果只需要判断真假，可用
TRY_CAST(col AS INT) IS NOT NULL - 注意类型选择：
TRY_CAST('123.45' AS INT)返回NULL，但TRY_CAST('123.45' AS DECIMAL(5,2))成功 - 性能上，
TRY_CAST一次执行完成判断+转换，比ISNUMERIC+CAST两步更优且无竞态风险
不同SQL方言里没有ISNUMERIC怎么办？
PostgreSQL、MySQL、SQLite都不提供ISNUMERIC，需用正则或异常处理模拟。
- PostgreSQL：用
col ~ '^[-+]?d*.?d+$'只能覆盖简单小数，无法处理科学计数法；更稳的是写EXCEPTION块或用pg_typeof()辅助 - MySQL 8.0+：可用
CAST(col AS SIGNED)配合IFNULL，但失败时会截断或静默转0，不推荐；建议用REGEXP '^-?[0-9]+(\.[0-9]+)?$'做前置过滤 - SQLite：没内建数值校验，
typeof(col) = 'text'不能说明是否可转，必须靠CAST(col AS REAL)后对比原值或检查是否为NULL
为什么WHERE子句里用ISNUMERIC容易出错？
看似合理的过滤语句WHERE ISNUMERIC(col) = 1 AND CAST(col AS INT) > 100可能运行时报错——优化器可能先执行CAST再过滤，导致对'1e3'这类值强制转换失败。
- SQL Server不保证
WHERE中逻辑短路，不能依赖ISNUMERIC挡掉非法值 - 正确写法是把转换逻辑放进
TRY_CAST，再比较：WHERE TRY_CAST(col AS INT) > 100 - 若必须用旧版本SQL Server（无TRY_*函数），需用
CASE WHEN ISNUMERIC(...) = 1 THEN CAST(...) ELSE NULL END包裹转换
ISNUMERIC返回1之后，CAST突然崩掉——尤其当数据来自外部导入或用户输入时，那些看似合法的符号（如千分位逗号、货币符号、全角数字）才是隐形炸弹。 
