MySQL中REGEXP无法单模式覆盖所有数字语义，需按整数、带符号、小数、科学计数法等场景拆解；硬套“万能表达式”易误判，推荐优先用CAST配合TRIM和空值检查。
MySQL中用REGEXP判断字符串是否为纯数字（含正负号和小数点）
直接结论：MySQL的REGEXP不能靠单个模式覆盖所有“数字”语义，必须按需拆解——你要的是整数？带符号？允许科学计数法？还是只要能被CAST成数字就行？不同场景正则写法完全不同，硬套一个“万能表达式”反而常出错。
常见错误是写成'^[0-9]+$'，它连'-123'或'3.14'都判为非数字，而业务里这些明显是数字。更糟的是，有人用'^-?[0-9]+.?[0-9]*$'，结果'.'、'-.'、'123.'全被放过——它们根本不是合法数字。
-
^[-+]?[0-9]+(.[0-9]+)?$：匹配带可选符号的常规小数，如'123'、'-45.67'，但拒绝'123.'和'.5' -
^[-+]?([0-9]+.?[0-9]*|.[0-9]+)([eE][-+]?[0-9]+)?$：支持科学计数法，如'1.23e-4'，但写错括号或量词容易漏掉边界情况 - 若只需“能被MySQL转成数字”，不如直接用
CAST(col AS SIGNED)或CAST(col AS DECIMAL)配合IS NOT NULL，更可靠且兼容隐式转换逻辑
为什么REGEXP在MySQL里对数字校验特别容易翻车
MySQL的正则引擎（尤其是5.7及以前）不支持d、不支持lookahead/lookbehind，且REGEXP默认是多行模式，^和$可能意外匹配换行符内部位置。最隐蔽的坑是空字符串''和全空白字符串（如'
'）——它们用^[0-9]*$会返回1（真），但显然不是数字。
- 务必用
TRIM()预处理：TRIM(col) REGEXP '^[-+]?[0-9]+(\.[0-9]+)?$' - 注意MySQL 8.0+才支持
REGEXP_LIKE()，旧版本只能用col REGEXP '...'，且大小写敏感性依赖collation -
NULL值在REGEXP中结果为NULL，不是0，需显式加col IS NOT NULL
实际查数据时怎么写安全的条件语句
别只写WHERE col REGEXP '...'，生产环境必须叠加类型过滤和长度限制。比如校验用户输入的金额字段，预期是≤10位整数或2位小数：
WHERE
col IS NOT NULL
AND TRIM(col) != ''
AND LENGTH(TRIM(col)) <= 13
AND TRIM(col) REGEXP '^[-+]?[0-9]{1,10}(\.[0-9]{1,2})?$'
这里{1,10}强制整数部分非空且不超长，(.[0-9]{1,2})?确保小数点后只有1–2位，彻底堵住'12345678901.123'这种越界输入。
- 如果字段可能含千分位逗号（如
'1,234.56'），先用REPLACE(col, ',', '')清洗再正则，否则正则永远过不了 - 性能上，
REGEXP无法走索引，大数据量表慎用；高频校验建议改用生成列+索引：ALTER TABLE t ADD is_num TINYINT AS (col REGEXP '^[-+]?[0-9]+(\.[0-9]+)?$') STORED
比正则更稳的替代方案：用CAST + 类型转换异常兜底
MySQL本身对数字转换有成熟逻辑，比手写正则更贴近真实业务含义。例如：CAST('123' AS SIGNED)成功返回123，CAST('abc' AS SIGNED)返回0并告警，CAST('123abc' AS SIGNED)截断为123——这恰恰是多数场景想要的行为。
所以更推荐：
WHERE col IS NOT NULL AND TRIM(col) != '' AND CAST(TRIM(col) AS SIGNED) != 0 OR TRIM(col) REGEXP '^0$|^[-+]?0+\.0*$'
最后一行补了对'0'、'-0.0'等零值的覆盖，因为CAST('0' AS SIGNED)是0，但CAST('' AS SIGNED)也是0，必须靠TRIM和空值检查隔离。
真正难处理的是那些MySQL认为“可转换”但业务不允许的值，比如'1e1000'（溢出为0）或'∞'（某些版本返回NULL）。这种边界得结合应用层校验，别指望SQL单挑全部。
