MySQL中判断纯数字应使用REGEXP：'^[+-]?[0-9]+.?[0-9]*$'匹配整数及小数（如123、-45.67），需配合IS NOT NULL处理NULL；5.7版本不支持+量词时可用{1,}替代，且不可见字符需显式枚举。
用 REGEXP 判断字段是否为纯数字（含正负号和小数）
MySQL 没有内置的 IS_NUMERIC() 函数，最直接可靠的方式是用正则表达式。但要注意：不同 MySQL 版本对正则的支持差异很大。REGEXP 在 8.0+ 默认使用 ICU 引擎，行为更标准；5.7 及以前用的是老式 POSIX 风格，不支持 ^/$ 锚点在某些上下文中生效。
判断「纯数字」（允许开头的 +/-、一位小数点、非空）建议用：
col REGEXP '^[+-]?[0-9]+.?[0-9]*$'
这个模式能匹配 123、-45.67、+0.0，但拒绝 12.34.56、.5、12.、abc。如果业务允许省略整数部分（如 .5），改用：^[+-]?([0-9]+.?[0-9]*|.[0-9]+)$。
- MySQL 5.7 中
REGEXP不支持+量词？可用[0-9]{1,}替代 - 空字符串
''和NULL都不匹配该正则，需额外用col IS NOT NULL控制 - 性能上，正则无法走索引，大数据量时慎用于
WHERE条件
用 CAST() + CONVERT() 辅助验证（仅适用于整数场景）
当字段预期是整数（不含小数点），可以用类型转换反推：把字符串转成数字再转回字符串，看是否一致。例如：
col = CAST(CAST(col AS SIGNED) AS CHAR)
这个技巧依赖 MySQL 的隐式转换规则：对非数字字符（如 '123abc'），CAST(... AS SIGNED) 会截断取前缀数字（变成 123），再转回字符串就和原值不等了。但它对 'abc123' 返回 0，而 CAST('abc123' AS SIGNED) 结果是 0，CAST(0 AS CHAR) 是 '0'，所以 'abc123' = '0' 为假 —— 这反而能识别出非法值。
- 只适合整数校验，
'12.3'转SIGNED会变成12，再比对失败，误判为非法 - 遇到溢出（如超大数字）可能转成
NULL或边界值，导致逻辑错乱 - 不能区分
'0'和'00'，因为两者转整数都是0
识别包含特殊字符（非字母数字下划线）的字段
如果目标是「找出含特殊字符的记录」，比如日志字段里混入了控制字符、emoji、全角符号或 SQL 注入痕迹，正则依然最稳：
col REGEXP '[^a-zA-Z0-9_[:space:]]'
这里 [^...] 表示「不在集合内的任意一个字符」，[:space:] 匹配空格、制表符、换行等。注意：MySQL 5.7 不支持 POSIX 字符类 [:space:]，得写成 [^a-zA-Z0-9_
]。
- 中文字符会被此正则捕获（因不在 a-zA-Z0-9_ 范围内），若业务允许中文，需显式加入
\u4e00-\u9fa5（MySQL 8.0+ 支持 Unicode 属性，但写法更复杂） -
NULL值在REGEXP中结果为NULL，不是FALSE，记得加col IS NOT NULL - 想排除所有不可见字符（如零宽空格 U+200B），正则必须显式列出或用
HEX(col)辅助分析
为什么不用 IS_NUMBER() 或自定义函数？
MySQL 官方至今没提供 IS_NUMBER() 这类标量函数。有人试图用存储函数封装正则逻辑，但实际中问题不少：
- 函数体内不能直接用参数名做正则模式（MySQL 不支持动态正则），只能写死模式或拼接字符串，失去通用性
- 函数调用开销比内联正则高，尤其在
WHERE中被反复执行时 - 权限限制：创建函数需要
CREATE ROUTINE权限，很多生产环境禁用 - 版本兼容性差：MySQL 8.0 的
REGEXP_SUBSTR()等新函数，在 5.7 下完全不可用
真正难处理的其实是带千分位逗号、货币符号、科学计数法（如 1.23E+4）的“数字字符串”——这些必须按业务规则拆解，没有通用正则能一劳永逸。别指望一个表达式覆盖所有财务系统里的数字格式。
