MySQL中查字段含数字应使用'[0-9]'或'[:digit:]'，不可用'd'；性能差需避免全表扫描，推荐生成列+索引；5.7与8.0正则语法差异大，须按版本适配。
MySQL 用 REGEXP 查字段里有没有数字，得写对模式
MySQL 的 REGEXP 不支持 d 这种简写，直接写 '\d' 或 'd' 都会查不到——它只认 POSIX 字符类。想查含数字的记录，得用 [0-9] 或更宽松的 [[:digit:]]。
常见错误是照搬其他语言正则习惯，比如写 WHERE col REGEXP '\d+'，结果全空；或者漏掉引号，写成 REGEXP d，直接报语法错。
-
WHERE col REGEXP '[0-9]'：最常用，匹配字段中任意位置出现至少一个数字 -
WHERE col REGEXP '^[0-9]+$'：整字段全是数字（注意空格会导致失败） -
WHERE col REGEXP '[[:digit:]]'：等价于[0-9]，语义更清晰，但写法稍长
中文、字母混排时，REGEXP 仍能准确定位数字
只要字段值里存在 ASCII 数字字符（0–9），不管前后是汉字、英文字母还是符号，REGEXP '[0-9]' 都能捕获。比如 '订单编号：ORD-2024-001'、'价格￥99.5元'、'测试abc123def' 全部命中。
但要注意：Unicode 数字（如全角数字 １２３）不会被 [0-9] 匹配，MySQL 原生不支持 Unicode 属性类（如 p{Nd}），这类需求得靠应用层处理或升级到 MySQL 8.0+ 并确认 collation 支持。
- 全角数字需单独写进模式，例如
'[0-9０-９]'（后者是 Unicode 全角 0–9） - 字段含换行符时，
REGEXP默认跨行匹配，无需额外标志 - 大小写不敏感由列的 collation 决定，和
REGEXP本身无关
REGEXP 查询性能差？这些操作会雪上加霜
MySQL 对 REGEXP 几乎无法使用索引（除非是前缀固定且极短的特殊情况），全表扫描是常态。一旦表超过几万行，响应延迟就很明显。
容易被忽略的性能雷区：
- 在
WHERE中对函数结果用REGEXP，比如REGEXP UPPER(col)，彻底放弃任何潜在优化可能 - 用
NOT REGEXP判定“不含数字”，逻辑上等价但执行计划更差，MySQL 往往放弃优化器提示 - 在
ORDER BY或GROUP BY里嵌套REGEXP表达式，会强制生成临时表 + 文件排序 - 替代方案优先考虑：加生成列 + 索引，例如
ALTER TABLE t ADD has_digit TINYINT AS (col REGEXP '[0-9]') STORED, ADD INDEX idx_has_digit(has_digit)
MySQL 5.7 和 8.0 的 REGEXP 行为差异不能忽略
MySQL 8.0 重写了正则引擎，支持更多语法（如 +、?、{n} 量词默认启用），而 5.7 默认只支持基本正则（BRE），部分写法行为不一致。
典型差异点：
- MySQL 5.7 中
'a+b'的+被当字面量，要写成'a\+b'才表示“a 后跟 b”；8.0 默认按 ERE 解析，+是量词 -
REGEXP '^[0-9]{3,5}$'在 8.0 可用，在 5.7 会报错，得改写为'^[0-9][0-9][0-9][0-9]?[0-9]?^'（不推荐）或用应用层过滤 - 8.0 支持
REGEXP_LIKE()函数，参数更明确（如可指定匹配模式'c'忽略大小写），但 5.7 只有操作符形式
线上环境务必先查 SELECT VERSION()，别假设版本一致。跨版本迁移时，正则表达式得重新验证。
