isnumeric不可靠因其判断范围过宽，会将'123.'、'$123'等非纯数字字符串误判为数字；应改用like配合trim和长度检查，或sql server 2016+的try_cast。
ISNUMERIC函数在SQL Server中为什么不可靠
ISNUMERIC 只判断字符串能否被转换为任意一种数字类型（包括 money、float，甚至带逗号或加减号的字符串），不是“是否为纯整数/小数”的可靠指标。比如 ISNUMERIC('123.')、ISNUMERIC('$123')、ISNUMERIC('1e4') 全部返回 1，但它们显然不符合“纯数字字符串”需求。
常见误用场景：用它校验用户输入的手机号、订单编号、身份证前缀等字段是否“只含数字”，结果放行了非法值。
- 它不区分整数/浮点/科学计数法/货币格式
- 它对空格、正负号、小数点、千分位符（如
'1,234'）都返回 1 - 它对
NULL返回 0，但对空字符串''也返回 0 —— 这容易掩盖空值逻辑
SQL Server里真正判断“纯数字字符串”的写法
要严格匹配“仅由 0–9 组成的非空字符串”，最稳妥的是用 LIKE 配合否定模式 + 长度检查：
WHERE LEN(TRIM(col)) > 0 AND col NOT LIKE '%[^0-9]%' AND col LIKE '[0-9]%'
说明：
-
TRIM(col)去首尾空格（SQL Server 2017+；老版本用RTRIM(LTRIM(col))） -
LEN(...) > 0排除空字符串 -
col NOT LIKE '%[^0-9]%'表示“不存在任何非数字字符” -
col LIKE '[0-9]%'确保至少以一个数字开头（排除空串和纯符号串）
注意：LIKE '[^0-9]' 在部分排序规则下可能匹配失败（如带重音字符的 collation），建议显式指定二进制比较：col COLLATE Latin1_General_BIN NOT LIKE '%[^0-9]%'
SQL Server 2016+ 可用 TRY_CAST 做安全整数判断
如果目标是“能转成 INT 的纯整数字符串”，TRY_CAST 比 ISNUMERIC 更精准：
WHERE TRY_CAST(col AS INT) IS NOT NULL
但它仍有局限：
- 会拒绝带前导零的字符串（如
'007'转INT是合法的，但业务上可能要求保留格式） - 会拒绝超过
INT范围的数字（如'2147483648'），此时需换用BIGINT或DECIMAL - 它允许
' 123 '（带空格）成功转换 —— 所以仍建议先TRIM
若需支持小数，改用 TRY_CAST(col AS DECIMAL(18,2))，但要注意精度丢失风险（如 '123.456' 转 DECIMAL(18,2) 会被截断）。
正则？SQL Server原生不支持，别硬套
SQL Server 直到 2022 版才通过 STRING_SPLIT + 外部 CLR 或 REGEXP_LIKE（需启用 Azure SQL 或特定兼容级别）提供有限正则能力。本地 SQL Server（2019 及更早）没有 REGEXP 函数，所谓“用正则判断数字”实际是误导。
有人用 master.dbo.xp_cmdshell 调外部工具、或建 CLR 函数实现正则 —— 这些方案：
- 需要高权限，生产环境通常禁用
xp_cmdshell - CLR 需开启
TRUSTWORTHY或签名，DBA 往往拒绝部署 - 性能比
LIKE差一个数量级，且无法走索引
真要正则能力，优先考虑把校验逻辑移到应用层（如 C# 的 Regex.IsMatch(s, @"^\d+$")），而不是在 SQL 里强行补漏。
复杂点在于：业务定义的“纯数字”未必是数学意义上的——比如是否允许前导零？是否接受空字符串？是否区分全角数字？这些边界必须和产品对齐，不能只看 SQL 函数返回什么。
