MySQL中用REGEXP判断字符串是否全为数字的正确写法是col REGEXP '^[0-9]+$'，但需配合col IS NOT NULL和TRIM(col)预处理，以排除空值、空格及非数字字符；该模式仅匹配纯非负整数，不支持符号、小数点或科学计数法。
MySQL中用REGEXP判断字符串是否全为数字的正确写法
直接用 column_name REGEXP '^[0-9]+$' 是常见但有隐患的做法：它会把空字符串、带正负号的整数（如 '-123'）、科学计数法（如 '1e5'）全部判为 false，而多数业务场景下，你其实只关心“纯非负整数字符串”。如果字段可能含前导空格或 NULL，还得额外处理。
-
^[0-9]+$：匹配一个或多个数字，不接受空串，不接受符号，不接受小数点 -
^[[:digit:]]+$：等价于上一条，更 POSIX 兼容，但 MySQL 中效果一致 - 若需允许空字符串，改用
^[0-9]*$；但注意这会让空串和纯数字都返回 true - NULL 值在
REGEXP中结果恒为 NULL，必须显式用IS NOT NULL过滤
为什么^[0-9]+$在某些情况下返回NULL而不是0或1
根本原因是 MySQL 的 REGEXP 操作符对 NULL 输入返回 NULL，不是布尔 false。比如 SELECT NULL REGEXP '^[0-9]+$' 结果就是 NULL，不是 0。这会导致 WHERE 条件意外跳过整行——尤其当字段允许 NULL 且你没意识到时。
- 安全写法是：
col IS NOT NULL AND col REGEXP '^[0-9]+$' - 想统一转成布尔值？可用
IF(col REGEXP '^[0-9]+$', 1, 0)，但要注意 NULL 输入仍得先处理 - 别依赖隐式转换，例如
WHERE (col REGEXP '...') = 1在 NULL 时整个表达式为 NULL，条件不成立
区分整数、小数、带符号数的REGEXP模式选择
业务中“全是数字”常有不同含义。MySQL 的 REGEXP 不支持 d 简写（5.7 及以前），也不支持 Unicode 数字，所以得靠字符集范围手动控制。
- 非负整数（推荐默认）：
^[0-9]+$ - 可选正负号的整数：
^[+-]?[0-9]+$（注意+在正则里是量词，必须转义或放开头/结尾；这里放开头无需转义） - 支持一位小数（如
'123.45'）：^[0-9]+(\.[0-9]+)?$（注意小数点要双反斜杠转义） - 严格小数（不能是整数）：
^[0-9]+\.[0-9]+$ - 不推荐匹配浮点科学计数法——MySQL 自身类型转换更可靠，正则易出错
REGEXP性能差？替代方案有哪些
REGEXP 在 WHERE 中无法使用普通 B+Tree 索引，全表扫描风险高。如果只是校验“是否能转成整数”，CAST + 类型比较反而更快也更语义清晰。
- 替代写法：
col != '' AND col = CAST(col AS UNSIGNED)（适用于非负整数） - 原理：MySQL 将字符串转为无符号整数时，遇到非数字字符会截断，比如
CAST('123abc' AS UNSIGNED)得 123，再跟原字符串比就不同 - 缺点：对超大数字（超过
UNSIGNED INT范围）会溢出为 0 或最大值，需结合长度判断 - 如果字段上有函数索引（MySQL 8.0+），可建
ALTER TABLE t ADD INDEX idx_num ((col REGEXP '^[0-9]+$'))加速
真正麻烦的不是写哪个正则，而是想清楚你要排除什么：空格？前导零？负号？小数点？还有 NULL 怎么算——这些决定了正则边界和配套的 NULL 处理逻辑，漏掉任意一项，线上就可能出意料之外的匹配结果。
