SQL正则表达式指南：REGEXP语法、数据库差异与优化实战

我见过太多把几十个 LIKE 条件拼成长篇大论的业务SQL，尤其处理手机号、邮箱、备注这些非结构化字段的时候——你明明想表达的是同一套规则，写出来却像一场灾难。REGEXP 正则表达式的作用就是把这些“长串里面找东西”的查询，从“字符包含”升级成“格式匹配”：只判断包含某个子串，你要用 LIKE；一旦规则涉及几位数字、什么开头、什么结尾、中间是否混入其他字符，再堆 LIKE 就是自找麻烦。这篇 SQL 中 REGEXP 正则表达式使用指南会从不同数据库实现差异讲到可以直接抄的清洗案例，再补上我这几年来在匹配性能、转义字符、大小写和 NULL 语义上面反复踩过的坑。

我不会推荐一种通用的正则写法就完事——因为 MySQL、PostgreSQL、Oracle、SQLite 这些看起来都叫“SQL”，对正则在语法上的支持程度完全不是一回事。先把这些差异讲清楚，后面积累的模式才不会用错地方。

1. 先查版本再入门：各主流数据库对 REGEXP 的支持差距

写正则前第一件事不是背语法，而是确认你在哪个数据库上干活。同一个 ^1[3-9][0-9]{9}$，在 MySQL 里可以直接写在 WHERE 后面，在 PostgreSQL 里要换成波浪号 ~，在 SQL Server 里干脆会直接报错。

1.1 MySQL：REGEXP 和 RLIKE，最容易上手也最容易被误导

MySQL 的 REGEXP 是一个返回布尔值的运算符，RLIKE 是它的等价写法，两个词随便你用哪个。老版本 MySQL 5.7 里，你基本只能做一件事：在条件里判断某个字段是否符合某个正则模式。

code复制SELECT id, mobile
FROM member
WHERE mobile REGEXP '^1[3-9][0-9]{9}$';

到了 MySQL 8.0 这一代，正则能力才补齐，官方引入了 REGEXP_LIKE()、REGEXP_INSTR()、REGEXP_SUBSTR()、REGEXP_REPLACE() 这一整套函数。这带来一个最常见的误区：你在网上搜到一篇 MySQL 正则教程，照着里面的函数在 5.7 里跑，结果直接报“FUNCTION does not exist”。所以第一步必须看清版本，5.7 和 8.0 能用的东西差了一大截。

1.2 PostgreSQL：没有叫 REGEXP 的运算符，但有更顺手的波浪号

很多从 MySQL 转过来的同学在 PostgreSQL 里敲 REGEXP，发现压根不认，因为 PostgreSQL 走的是 POSIX 正则路线，匹配运算符是 ~、~*、!~、!~*。~ 表示区分大小写匹配，~* 表示不区分大小写匹配，前面加 ! 就是否定匹配。

code复制SELECT id, email
FROM account
WHERE email ~ '^[^@]+@[^@]+$';

PostgreSQL 还提供了 regexp_matches()、regexp_replace()、regexp_substr() 之类的函数，功能上比 MySQL 老版本强很多，但在写 SQL 时会发现，网上的 MySQL 正则案例几乎不能直接复制到 PG 上运行。

1.3 SQL Server：没有原生 REGEXP，最容易被坑

无数人在 SQL Server 里执行 SELECT * FROM table WHERE col REGEXP '...'，然后一脸懵地看着语法错误。SQL Server 的 T-SQL 从设计上就没有提供通用正则表达式运算符，这是硬伤。它的 LIKE 自带一小套通配符（%、_、[abc]、[^abc]），能覆盖部分简单场景，但一旦遇到“校验一个字符串是否为合法 IPv4 地址”这类需求，T-SQL 原生写法会非常痛苦。

如果你在 SQL Server 里真的需要完整正则能力，通常只能走几条路：注册 CLR 自定义函数、用第三方扩展、或者把要清洗的数据交给外部 ETL 工具处理。对大多数只在数据库里做临时查询的同学来说，最现实的建议是：先评估一下需求是否能用 LIKE 加几个通配符解决，能解决就别上正则。

1.4 SQLite 和 Oracle：REGEXP 的打开方式完全不同

SQLite 默认把 REGEXP 运算符保留下来了，但默认没有实现，直接使用会报错，需要你自己在客户端或驱动层注册一个正则函数，这一点坑过很多把 SQLite 当 MySQL 用的人。

Oracle 则提供了 REGEXP_LIKE、REGEXP_INSTR、REGEXP_SUBSTR、REGEXP_REPLACE、REGEXP_COUNT 这一整套函数，使用方式跟 MySQL 8.0 很像，但又多了 POSIX 字符类支持上的细微差异。

为了让你看得更直接，我把常见操作在不同数据库里的对应写法列成一张表：

这张表看一眼就知道，所谓“SQL中的REGEXP”其实是一个覆盖面很大的说法，你必须先定位自己用的数据库版本，再决定后面的正则该怎么写。

2. 正则符号没那么玄，配合 SQL 的实际行为理解就顺了

很多人的误区是捧着正则语法大全从头背到尾，背完还是不知道怎么写。我建议反过来，你只需要掌握几组基础规则，然后结合 SQL 的字段匹配场景去验证：第一是字符类，第二是量词，第三是锚点和分组。这三样东西足够覆盖 80% 的业务筛选需求。

2.1 字符类：精确表达“该位置能出现哪些字符”

正则中最基本的单元是字符类。比如只想要数字，[0-9] 是最直白的写法；只想要字母，用 [a-zA-Z]；只想表示一个任意字符，用 .。注意 . 在 SQL 正则里是“任意单个字符”的意思，而不是肉眼看到的句号，这个和很多人写文案时的理解不一样。

我在实际处理中更推荐用 POSIX 字符类，比如 [[:digit:]] 表示数字、[[:alpha:]] 表示字母、[[:space:]] 表示空白。原因很直接：在某些数据库或编码环境下，[0-9] 与 [[:digit:]] 的结果还有可能被字符集影响，但写 POSIX 类通常更稳定。MySQL、PostgreSQL、Oracle 对 POSIX 类的支持都比较成熟。

2.2 量词：告诉正则这个字符该出现几次

单靠字符类只能控制单个位置，配合量词才能表达长度规则。

• *：前面的字符出现 0 次或多次
• +：前面的字符出现 1 次或多次
• ?：前面的字符出现 0 次或 1 次
• {m}：前面的字符必须出现 m 次
• {m,n}：前面的字符出现 m 到 n 次

比如校验手机号 ^1[3-9][0-9]{9}$，拆开理解就是：第一个字符必须是 1，第二个字符是 3 到 9，后面 9 位必须全是数字，加起来刚好 11 位。很多同学会写成 [0-9]*，那是允许空字符串的宽松写法，字段为 888888 也会通过，根本起不到校验作用。

用生活化类比：字符类相当于告诉你“这个位置允许停什么车”，量词相当于告诉你“这个停车位能停多长的车”，两者配合起来，你才真正把一整条规则描述清楚。

2.3 锚点、分组和或：让模式有边界、能够被组合

锚点 ^ 和 $ 分别表示字符串开头和结尾。这条太重要了，因为 LIKE 默认就是模糊包含，导致很多人写正则时不自觉地丢掉锚点。比如你要查“备注里出现了999结尾的订单号”，如果只写 REGEXP '[0-9]{3}$' 没问题；但如果你想校验整段文本就必须用 ^ 和 $ 把两头钉死。

分组用小括号 () 表示，它会改变匹配优先级，也可以配合量词使用。比如邮箱的本地部分常见规则是允许点号或下划线，但结尾又必须是一个点分隔的域名结构，括号能很好地把“一个整体”圈起来。

或操作符是竖线 |，它表示“左边或右边任一满足即可”。比如要同时匹配 .com 和 .cn 结尾：

code复制SELECT domain
FROM site
WHERE domain REGEXP '\\.(com|cn)$';

注意这里用了 \\.，因为在正则里点号有“任意字符”的含义，要匹配字面意义上的点号必须先转义。这个转义问题在 SQL 里引发的连锁反应，我会在后面的暗坑章节详细展开。

3. 不要把 REGEXP 用成高级 LIKE，这些场景才是它的主场

我见过不少项目把 REGEXP 用得很浪费，明明一个规则就能做完整校验，却拆成好几个 LIKE 再叠加 OR，极大拖慢查询速度。正则真正发力的地方是文本格式校验、日志片段提取、字段清理，以及作为数据质量约束。

3.1 让查询条件变成完整的规则判断

当你需要判断“这个字段是不是一个合法手机号”“是否包含非法字符”“是否是固定格式的单号”的时候，LIKE 会写得极其啰嗦，而 REGEXP 只需要一句话。

code复制-- MySQL
SELECT id, username
FROM user
WHERE invite_code NOT REGEXP '^[A-Z0-9]{8}$';

-- PostgreSQL
SELECT id, username
FROM user
WHERE invite_code !~ '^[A-Z0-9]{8}$';

这个例子要检查邀请码是否不符合规则，如果有一行数据混进小写字母或长度不对，就会被筛出来。老手和新手在这里的差别，往往就在能不能意识到：你不是要“找什么”，而是要“判断它是不是东西”，正则的否定判断非常值钱。

3.2 从日志字段里提取结构化片段

我在处理访问日志类数据时经常需要从一整段文本里抓 IP、抓时间戳、抓状态码。以前很多人是先整条拉出来，跑到应用层用代码处理，再写回数据库，效率很低。数据库原生支持正则提取函数后，可以直接在查询时提取。

如果在 MySQL 8.0 里处理日志：

code复制SELECT
  id,
  REGEXP_SUBSTR(log_text, '[0-9]+([.][0-9]+){3}') AS ip_addr,
  REGEXP_SUBSTR(log_text, '[0-9]{4}-[0-9]{2}-[0-9]{2}') AS event_date,
  REGEXP_SUBSTR(log_text, '\\[[0-9]{2}:[0-9]{2}:[0-9]{2}\\]') AS event_time
FROM access_log
WHERE log_text REGEXP 'error|failed';

为什么这里写 [.] 而不是 \\.？因为方括号里的点号已经失去了“任意字符”的语义，不需要转义也能精确匹配点号。这个技巧会极大减少你的转义痛苦，后面我还会再提。

在 PostgreSQL 里，提取逻辑更接近函数式：

code复制SELECT id,
       (regexp_match(log_text, '[0-9]+([.][0-9]+){3}'))[1] AS ip_addr
FROM access_log
WHERE log_text ~ 'error|failed';

regexp_match() 返回的是一个数组，取 [1] 才能拿到第一个匹配文本。很多人第一次写会漏掉这个下标，导致查询结果不是直接字符串而是一个奇怪的 PostgreSQL 数组对象。

3.3 数据清洗时能少写十几行 CASE WHEN

清理脏数据是另一个典型场景。比如姓名列里混入了多余空格和多个标点，你不需要先查出来再写代码改，直接在 SQL 里用替换函数一把刷干净。

MySQL 8.0：

code复制UPDATE member
SET real_name = REGEXP_REPLACE(
  REGEXP_REPLACE(real_name, '[[:space:]]+', ''),
  '[,，;；]+', ' '
);

PostgreSQL 的替换函数额外多一个参数用来表示是否替换所有出现位置，很多人会漏掉第四个参数的 'g'，结果只替换掉第一个匹配项：

code复制UPDATE member
SET real_name = regexp_replace(
  regexp_replace(real_name, '[[:space:]]+', '', 'g'),
  '[,，;；]+', ' ', 'g'
);

这两段代码的核心价值在于，把原来要写十几行 CASE WHEN REPLACE(REPLACE(...)) 才能做的多重清洗，收敛成一个正则表达式。真实脏数据往往不止一种不合法字符，规则越统一，这里的收益越明显。

3.4 从源头用 CHECK 约束卡住数据格式

正则不止能用在查询，还能用在建表约束上。PostgreSQL 里这样写很自然：

code复制ALTER TABLE member
ADD CONSTRAINT chk_mobile_format
CHECK (mobile ~ '^1[3-9][0-9]{9}$');

MySQL 从 8.0.16 开始才真正执行 CHECK 约束，之前的版本会把这条约束解析成功但在写入时直接忽略，所以如果你还在用 5.7，这个写法不要作为依赖。Oracle 也有类似约束能力，但语法上是用 REGEXP_LIKE 函数而不是运算符。

把正则写进约束之后，任何不符合规则的写入会在数据库层面被直接拒绝，而不是等到业务层跑半天才发现数据是脏的。这个思路对于新表设计很有用，但对已经存在大量脏数据的老表，不要一上来就加约束，否则全表更新会被拦截，最好先做一轮清洗。

4. 正则一写查询就慢？先搞清楚为什么不能走索引

凡是正则用在 WHERE 条件里，数据库基本都要把字段值一个一个拿出来做模式匹配，这意味着正常的 BTREE 索引对这类查询大概率是无效的。很多团队抱怨“慢SQL优化难”，其实是没意识到正则天然与索引不兼容，还在试图靠加索引解决。

4.1 REGEXP 不走索引，不是因为写法不对

以 MySQL 为例，WHERE mobile REGEXP '^139[0-9]{8}$' 就算 mobile 上有索引，优化器也往往不会选择索引。原因是正则匹配必须取出完整字段值，再在内存里跑一遍匹配引擎，而 B+ 树索引只支持前缀、范围这类有序查找，无法直接告诉引擎哪些行会命中正则。

简单说：LIKE '139%' 这种有固定前缀的查询，还有可能用上索引，因为数据库能计算出索引范围；但 REGEXP '^139[0-9]{8}$' 虽然看起来也是“以 139 开头”，数据库的优化器通常没有能力把这层规则翻译成索引范围。

所以你需要接受一个事实：正则更适合做“过滤后的二次筛选”，而不是拿来做全表扫描的第一道过滤条件。

4.2 既想正则校验，又不想全表扫：用可控前缀当第一道闸

我经常推荐的优化方式是，把正则中可作为前缀或者最容易限定的那部分拆出来，先用普通索引字段缩小数据量，再对剩余结果做正则匹配。比如查询手机号前缀为 139 且整体符合规则的数据，可以先建一个手机号前缀的生成列，再创建索引，最后查询时把前缀条件和正则在同一个 WHERE 里组合。

code复制ALTER TABLE member
ADD COLUMN mobile_prefix CHAR(3)
GENERATED ALWAYS AS (LEFT(mobile, 3)) STORED;

CREATE INDEX idx_mobile_prefix ON member(mobile_prefix);

SELECT id, mobile
FROM member
WHERE mobile_prefix = '139'
  AND mobile REGEXP '^139[0-9]{8}$';

这里的执行路径是：先用普通索引找到所有前缀为 139 的记录，数据量可能变成原来的十分之一甚至百分之一，然后再对这批记录跑正则，扫描成本自然大幅下降。生成列在 MySQL 和 PostgreSQL 都支持，是正则查询性能优化里最实用的手段之一。

如果数据库版本较老、不支持生成列，也可以在业务写入时单独冗余一列前缀字段，本质上是一样的思路。不要小看这个做法，很多慢 SQL 问题的根子就是第一道过滤条件太弱，导致正则要在百万行数据上跳舞。

4.3 多条过滤条件并存时，把正则放到最后

SQL 优化器对条件执行顺序的控制并不总是如你所想，但你在编写意识上应该有这样一个排序：先用日期范围、状态值、外键等成本最低的条件把数据切小，再把正则应放在靠近末端的位置。

举一个例子：你想找出“访问日志中某个时间段内出现 crash 关键字的记录”，如果写成：

code复制SELECT id, log_text
FROM access_log
WHERE log_text REGEXP 'crash'
  AND create_time >= '2025-01-01 00:00:00'
  AND create_time < '2025-02-01 00:00:00';

虽然 SQL 引擎可能会自动做代价判断，但从书写习惯上我倾向于把 create_time 这类索引友好条件写在前面，正则放最后。对于数据量大的日志表，时间范围能把上千万行压缩到几十万行，再跑正则会快得多。很多时候慢 SQL 不是正则本身太慢，而是你让它参与了本该避免的全量计算。

我以前遇到过一个极端案例，同事在千万级的订单表上直接 WHERE remark REGEXP '退款|售后'，这个查询跑了四十多秒，因为 remark 内容长、行数多，正则引擎要逐行逐字符扫描。后来加了时间分片和状态过滤，查询范围降到几十万行，耗时降到几百毫秒。正则可以表达很细的规则，但你要把它放在“精准命中少数数据”的位置，而不是让它做扫表的苦力。

5. 这些暗坑真的坑：转义、字符集、大小写与 NULL 语义

正则的语法错误会被数据库直接抛出，但还有一类错误是数据逻辑不对但语法完全正常，比如因为转义、编码、NULL 语义导致匹配结果不符合预期。这类问题不跑几个极端用例根本发现不了。

5.1 反斜杠转义在 SQL 字符串里的连环效应

大部分编程语言里可以写 \d 表示数字，但在 MySQL 的字符串中，反斜杠本身就是转义字符。你如果按其他语言习惯在 SQL 里写 '\d+'，MySQL 可能把 \d 解释成单纯的字母 d，或者直接把反斜杠吃掉，匹配结果完全不是你以为的意思。

正确做法往往要写两个反斜杠。比如匹配以数字开头的字段，MySQL 下要写成：

code复制SELECT *
FROM table_a
WHERE col_a REGEXP '^[0-9]+';

这里用 [0-9] 代替 \d，就是为了避开反斜杠地狱。如果需要匹配点号，我有两个写法供你选择：

code复制-- 写法1：双反斜杠转义
WHERE col_a REGEXP '^1\\.1\\.1\\.1$';

-- 写法2：用字符类代替转义，更推荐
WHERE col_a REGEXP '^1[.]1[.]1[.]1$';

第二种写法是我这几年最想推荐给新人的技巧，因为 [.] 里的点号就是普通点号，不需要额外转义，肉眼也能看出意图。凡是遇到那些有特殊含义的符号，比如点、星号、问号、括号，先想想能不能放进方括号里，能的话尽量别去和反斜杠纠缠。

如果在应用层代码里拼 SQL，还要再叠加一层该语言自己的字符串转义，那就会变成四层、五层反斜杠，极容易写错。遇到这种情况，我的经验是彻底放弃反斜杠写法，改用字符类或者正则函数参数的预编译方式。

5.2 中文字符匹配：别迷信 Unicode 转义，直接写最稳妥

不少从 Java 或 Python 转过来的同学，习惯把中文写成 \u4e00-\u9fa5 这种区间，然后在 MySQL 或 PostgreSQL 里执行，发现根本匹配不到中文字符。原因很简单，SQL 正则不是 JavaScript，很多数据库根本不支持 \u 这样的写法。

我在实际处理中文备注、中文姓名、中文地址时，建议直接写中文字符本身，比如要查以“张”“王”“李”开头的姓名：

code复制SELECT *
FROM member
WHERE real_name REGEXP '^[张王李]';

这种写法在中文环境下简单、直观、可读性高。不要试图把一段中文字符转成什么 Unicode 区间，除非你非常确定目标数据库的正则引擎支持相应的转义语法，否则就是给自己挖坑。

数据库字符集也会影响匹配。如果字段本身是 utf8mb4，多数情况下中文可以正常匹配；但如果字段是 latin1 之类非 UTF 字符集，正则匹配时很可能出现乱码或者长度计算不一致。检查字符集是遇到中文匹配异常时的第一反应，而不是去折腾正则写法。

5.3 正则的 NULL 语义：查不出结果不等于不匹配

这是非常经典的一个坑：在 SQL 里使用 WHERE col REGEXP '^abc' 时，如果某行 col 是 NULL，正则表达式的结果不是 FALSE，而是 NULL。而在 WHERE 过滤中，NULL 会被当作“不满足条件”直接排除。所以当你看到结果行数明显少于预期，第一反应应该是：是不是有大量 NULL 字段被正则条件过滤掉了。

解决办法很简单，如果你确实想保留 NULL 记录，必须显式加上 OR col IS NULL：

code复制SELECT *
FROM table_a
WHERE col_a REGEXP '^[A-Z]'
   OR col_a IS NULL;

反过来，如果你就是要把非法格式和空值一起排除，那现有写法反而正好符合预期。理解 NULL 参与正则判断的结果不是 TRUE 也不是 FALSE，而是逻辑上的第三种状态，你就能解释很多“字段明明是空的为什么查不到”的疑问。

5.4 大小写敏感度随数据库版本和字符集漂移

正则匹配是否区分大小写，在不同数据库里规则不一样。PostgreSQL 里 ~ 区分大小写，~* 不区分，非常明确。Oracle 可以在函数里传第三个参数 'i' 控制。MySQL 老版本的行为往往依赖列的排序规则，比如 utf8mb4_general_ci 下默认不区分大小写，到了 utf8mb4_bin 下又区分了。

依赖这种隐式行为会让你在不同环境间迁移时莫名其妙踩雷。我的习惯是，在同一个查询里需要限定大小写时，尽量把字符集规则显式表达出来。

MySQL 8.0 可以这样用：

code复制SELECT *
FROM account
WHERE REGEXP_LIKE(email, '^[A-Z0-9._%+-]+@[A-Z0-9.-]+\\.[A-Z]{2,}$', 'c');

'c' 表示大小写敏感匹配，'i' 表示大小写不敏感。PostgreSQL 则直接用 ~*。这虽然只是一个小习惯，却能避免你在换库、换版本时被同一段正则反复戏弄。

6. 实用主义做法：把正则当成规则资产，而不是临时拼出来的字符串

最后一个想分享的经验，可能比任何具体语法都值钱：正则不应该散落在各个慢查询里，也不应该在每一处用到的地方靠记忆重新写一遍。我在团队里会建议建立一个“规则清单”，把这些散落的表达式变成可控的、可测试的数据资产。

比如你把订单号规则、手机号规则、邮箱规则、地址清洗规则这些正则整理成一张配置表，或者至少在代码库里单独维护一个模块，统一从配置中心读取。这样当业务规则变化的时候，只需要改一处，而不是肉眼搜索所有 SQL 找哪几个查询用到了同一段正则。

团队协作里经常出现这样的笑话：两个人写出的“校验手机号”正则，一个认 ^1[3-9][0-9]{9}$，另一个认 ^1[3456789]\\d{9}$，行为看似一样，但遇到边缘字符时可能产生不同结果。如果规则分散在数不清的临时查询里，你根本没法保证两条 SQL 的表达一致。把它收拢成一份可复用的规则清单之后，才算真正解决了问题。

另一个跟安全相关的提醒：正则校验只是格式验证，它不会保护你的数据库免受注入攻击。无论你用的是 MySQL 的 REGEXP、PostgreSQL 的 ~ 还是 Oracle 的 REGEXP_LIKE，都不能因为写了正则就把用户输入直接拼进 SQL。参数化查询永远是底线，正则表达式只是用来判断数据是否符合预期的工具，不能替代任何安全机制。

我在实际数据处理中还有一个体会：不要把正则写得太长太炫技。一条几十个字符、四五层括号套娃的正则往往只有写它的人自己看得懂，两周之后连本人也未必能一眼说清每个分组在干什么。遇到复杂规则，拆成两三条简单正则分步处理，或者在代码里加好注释，比写一条“一行大师级”正则更有利于长期维护。

如果要给这篇 SQL 正则表达式使用指南做个经验收尾，我最想强调的就是三句话：先确认数据库版本再决定语法方向，能用前缀过滤就不要让正则扫全表，遇到转义和编码问题先跳出来想一想字符类和字符集，而不是一头扎进反斜杠里。把这几件事做到位，REGEXP 才能真正成为你手上的高效率武器，而不是把查询拖垮的慢SQL来源。