ISNUMERIC函数常误判，因其判断标准是“能否转为任意数字类型”，而非“是否为纯数字字符串”，故‘1e4’、‘$123’、‘,’等均返回1；推荐用TRY_CAST替代，或结合PATINDEX做精确模式匹配。
ISNUMERIC函数在SQL Server中为什么经常误判
ISNUMERIC 看起来最直接，但它的设计目标是“能否转成任意一种数字类型”，不是“是否为纯数字字符串”。这意味着 ISNUMERIC('1e4')、ISNUMERIC('$123')、ISNUMERIC(',') 甚至 ISNUMERIC(' ') 都返回 1 —— 它们确实能被隐式转换（比如转成 float 或 money），但业务上你通常不认为它们是合法数字输入。
- 常见误判场景：带货币符号、科学计数法、千分位逗号、全角空格、负号后无数字（如
'-'） - 它不区分整数/小数/负数语义，只管“能不能 cast 成某个数字类型”
- SQL Server 2012+ 推荐用
TRY_CAST或TRY_CONVERT替代，更可控
用TRY_CAST判断是否为整数或小数更可靠
真正想表达“这个字符串能安全转成 INT 或 DECIMAL 吗？”，就该用 TRY_CAST。它失败时返回 NULL，成功则返回目标类型值，逻辑清晰且无歧义。
- 判断是否为有效整数：
TRY_CAST(col AS INT) IS NOT NULL - 判断是否为有效小数（含整数）：
TRY_CAST(col AS DECIMAL(18,6)) IS NOT NULL - 注意精度：
DECIMAL(18,6)覆盖常见业务精度，但若字段可能存超长小数（如金融计算），需按需调高 - 性能影响：比
ISNUMERIC略重，但现代 SQL Server 优化较好；索引无法直接加速这类表达式，大表慎用于 WHERE 条件
需要严格格式校验？用正则（SQL Server 2016+ 的PATINDEX或CLR）
如果要求必须是“非负整数”“带可选负号的整数”“最多两位小数的正数”等，TRY_CAST 不够细粒度，得靠模式匹配。SQL Server 原生不支持正则，但有替代方案：
- 用
PATINDEX模拟简单规则：例如只允许数字和一个点（且点不在开头/结尾）：PATINDEX('%[^0-9.]%', col) = 0 AND col NOT LIKE '.' AND col NOT LIKE '%.' AND col NOT LIKE '.%' AND LEN(REPLACE(col, '.', '')) > 0 - 更清晰的做法是写标量 UDF 封装
TRY_CAST+ 额外检查（如禁止前导零、限制小数位数） - SQL Server 2016+ 可启用 CLR 函数支持完整正则，但需 DBA 开启
TRUSTWORTHY或签名，生产环境常被禁用 - 注意：所有字符串匹配都对空格敏感，建议先
RTRIM(LTRIM(col))
MySQL 或 PostgreSQL 怎么办
不同数据库语法差异大，别套用 SQL Server 的 ISNUMERIC 习惯：
- MySQL：没有
ISNUMERIC，可用col REGEXP '^-?[0-9]+\.?[0-9]*$'（注意浮点边界），或CAST(col AS SIGNED) IS NOT NULL（但会截断小数） - PostgreSQL：直接用
col ~ '^[-+]?[0-9]*\.?[0-9]+$'，或更稳的col::NUMERIC IS NOT NULL（会抛异常，需包在 PL/pgSQL 中捕获） - 跨库兼容性差，业务层做校验往往比 SQL 层更灵活
TRY_CAST 判数字，还得长度是11、开头是1；金额字段不仅要可转 decimal，还要 ≥ 0。别让数据库替你做领域逻辑。 
