ISNUMERIC和ISDATE不可靠，因判断宽松且不校验目标类型；应优先用TRY_CAST/TRY_CONVERT精确转换校验，复杂规则移至应用层处理。
ISNUMERIC 为什么经常不准？
它只判断字符串能否被转换成任意一种数值类型（包括货币符号、科学计数法、甚至带空格的 1e2），但不保证能转成你想要的 INT 或 DECIMAL(10,2)。比如 ISNUMERIC('123.') 返回 1，但 CAST('123.' AS INT) 直接报错；ISNUMERIC('$123') 也返回 1，但多数业务场景里这不算合法数字。
常见错误现象：
- 表单提交后插入失败，日志显示 Conversion failed when converting the varchar value '123.' to data type int
- 数据清洗时漏掉带符号或单位的“伪数字”，后续计算出错
实操建议：
- 不要用 ISNUMERIC 做业务校验，仅作粗筛
- 需要精确判断整数/小数时，优先用 TRY_CAST（SQL Server 2012+）
- 示例：判断是否为有效整数：TRY_CAST(@input AS INT) IS NOT NULL
ISDATE 的坑比 ISNUMERIC 还多
它对格式极度宽容，ISDATE('2023-02-30') 居然返回 1（虽然那天不存在），ISDATE('13/13/2023') 也可能返回 1（取决于语言设置）。更危险的是，它把很多非日期字符串也认成日期，比如 ISDATE('1')、ISDATE('1/2') 全部返回 1 —— 因为 SQL Server 默认会补全成 1900-01-01 和 1900-01-02。
使用场景：
- 仅适用于快速排除明显乱码（如 'abc'、'2023-xx-yy'）
- 绝不能用于确认“这个值可安全转为 DATE”
实操建议：
- 替代方案一律用 TRY_CONVERT(DATE, @input) 或 TRY_CAST(@input AS DATE)
- 若需严格格式（如只接受 YYYY-MM-DD），先用字符串函数预检查：LEN(@input) = 10 AND @input LIKE '[0-9][0-9][0-9][0-9]-[0-1][0-9]-[0-3][0-9]'
- 注意语言环境影响：SET LANGUAGE English 可减少歧义，但不如 TRY_* 稳定
正则在 SQL Server 里怎么用才不翻车？
SQL Server 原生不支持正则匹配，PATINDEX 和 LIKE 功能有限，写复杂规则极易漏判或误判。比如想验证手机号，LIKE '[1][3-9][0-9][0-9][0-9][0-9][0-9][0-9][0-9][0-9]' 看似可以，但无法排除 11111111111 这类无效号段，也没法做长度归一化（带不带 +86？有无空格破折号？）。
性能与兼容性影响：
- PATINDEX('%[^0-9]%', @input) = 0 判断纯数字，看似简洁，但无法区分 000 和 0 的语义差异
- 复杂 LIKE 模式（尤其开头带通配符）会导致索引失效，大数据量下变慢
实操建议：
- 简单规则用 TRY_CAST + 字符串约束（如长度、首字符）组合判断
- 真需要正则逻辑，把校验提到应用层（C#、Python 等），SQL 只存已清洗数据
- 如果必须在 SQL 内处理，SQL Server 2016+ 可用 STRING_SPLIT 配合子查询模拟部分逻辑，但别硬刚邮箱、身份证等高精度规则
什么时候该放弃内置函数，直接 TRY_CAST？
当你发现要堆砌三层 ISNUMERIC + ISDATE + PATINDEX 才勉强覆盖 80% 场景时，说明方向错了。SQL Server 的 TRY_CAST 和 TRY_CONVERT 是原子操作：一次尝试转换，成功就返回值，失败就返回 NULL，不抛异常 —— 这才是校验的本质。
参数差异：
- TRY_CAST('123.45' AS DECIMAL(5,2)) 成功，TRY_CAST('123.456' AS DECIMAL(5,2)) 返回 NULL（精度溢出）
- TRY_CONVERT(DATE, '2023-02-30', 120) 返回 NULL（明确拒绝非法日期），而 ISDATE 会放行
实操建议：
- 所有输入字段校验，统一走 TRY_CAST(@input AS XXX)，XXX 是你实际要存的目标类型
- 配合 CASE WHEN TRY_CAST(...) IS NULL THEN 'invalid' ELSE 'valid' END 做分类
- 注意：TRY_CAST(NULL AS INT) 返回 NULL，不是错误，所以先判空再 cast 更稳妥
真正麻烦的从来不是语法怎么写，而是业务上到底要接受哪些“看起来像数字/日期”的边缘情况 —— 这个得和产品一起拍板，别让 SQL 函数替你做决定。
