REGEXP_LIKE 中文排序规则怎么配置或排查

我第一次把 REGEXP_LIKE() 用到中文字段时，误以为“排序规则”只影响 ORDER BY。真正让结果忽然变成 0 的，往往是表达式和模式没有使用同一套字符集/排序规则，或者 match_type 覆盖了默认的大小写行为。解决思路是：先统一 utf8mb4，再显式写 COLLATE，最后用函数和元数据查实际生效配置。

官方地址：https://dev.mysql.com/doc/refman/8.4/en/

为什么 REGEXP_LIKE 的结果会受排序规则影响

MySQL 8.4 文档规定，正则操作默认使用 expr 与 pat 参数的字符集和排序规则来判断字符类型并比较。这里的“排序规则”更接近比较规则，不是把查询结果按拼音或笔画排序。正则表达式先决定模式如何解释，再在这套字符比较规则下判断是否匹配。

如果数据列是 utf8mb4，但模式来自另一个字符集的字面量，MySQL 会按表达式的排序规则优先级和强制性规则处理，结果可能和“看起来相同的中文”不一致。不要只改数据库默认值就认为所有查询已修复。

先用 utf8mb4 和显式 COLLATE 固定比较规则

迁移旧表时，我会先把候选排序规则列出来，再选一套和业务要求一致的规则。_ci 表示不区分大小写，_cs 表示区分大小写；中文本身没有英文字母大小写，但同一查询里混合英文、数字或符号时仍会受到影响。

-- 先确认当前服务器是否提供目标中文排序规则
SHOW COLLATION LIKE 'utf8mb4%zh%';

-- 两端都显式指定同一套字符集与排序规则，避免依赖隐式继承
SELECT REGEXP_LIKE(
  _utf8mb4'订单中文' COLLATE utf8mb4_zh_0900_as_cs,
  _utf8mb4'订单' COLLATE utf8mb4_zh_0900_as_cs
) AS matched;

-- 不需要语言特定规则时，也可用通用 UCA 规则做明确比较
SELECT REGEXP_LIKE(
  _utf8mb4'Order订单' COLLATE utf8mb4_0900_ai_ci,
  _utf8mb4'order' COLLATE utf8mb4_0900_ai_ci,
  'i' -- i 明确要求忽略大小写，便于和默认行为区分
) AS matched;

若服务器没有目标规则，不要把名称硬写进生产 SQL；根据 SHOW COLLATION 的结果选择可用项。MySQL 官方也建议尽量使用 utf8mb4，而 utf8 在当前版本中是已弃用的 utf8mb3 别名。

按顺序排查列定义、连接设置和 match_type

结果不符合预期时，先确认数据真的以预期字符集存储，再看连接协商出来的规则，最后才看语句里的覆盖项。下面三组查询不会修改数据，适合放进迁移前后的回归记录。

-- 查看连接层实际采用的字符集与排序规则
SELECT @@character_set_connection AS charset_conn,
       @@collation_connection AS collation_conn;

-- 查看目标列的真实定义，不要凭数据库默认值猜测
SELECT COLUMN_NAME, CHARACTER_SET_NAME, COLLATION_NAME
FROM INFORMATION_SCHEMA.COLUMNS
WHERE TABLE_SCHEMA = DATABASE()
  AND TABLE_NAME = 'orders'
  AND COLUMN_NAME = 'title';

-- 查看本次表达式两端最终使用的排序规则
SELECT COLLATION(_utf8mb4'订单中文') AS expr_collation,
       COLLATION(_utf8mb4'订单') AS pat_collation;

随后检查 match_type：c 强制大小写敏感，i 强制大小写不敏感；如果同一个参数串里出现冲突选项，靠后的选项优先。二进制字符串则按二进制、大小写敏感方式处理，即使写了 i 也不能按普通文本理解。

用最小样例做迁移回归，不要只测一条中文

迁移后至少覆盖精确中文片段、混合英文大小写、NULL 和二进制输入。尤其要保留 NULL 断言，因为 expr 或 pat 为 NULL 时，函数结果不是 0，而是 NULL。

-- 用固定输入覆盖命中、未命中和 NULL 三种返回值
SELECT
  REGEXP_LIKE(_utf8mb4'华东订单', _utf8mb4'订单') AS hit_cn,
  REGEXP_LIKE(_utf8mb4'Order', _utf8mb4'order', 'c') AS hit_case_sensitive,
  REGEXP_LIKE(_utf8mb4'Order', _utf8mb4'order', 'i') AS hit_case_insensitive,
  REGEXP_LIKE(NULL, _utf8mb4'订单') AS null_input;

-- 确认表达式级 COLLATE 能独立于连接默认值工作
SELECT REGEXP_LIKE(
  title COLLATE utf8mb4_zh_0900_as_cs,
  _utf8mb4'订单' COLLATE utf8mb4_zh_0900_as_cs
) AS matched
FROM orders
WHERE id = 1; -- 只取一条固定样本，便于迁移前后对照

如果旧环境使用的是 REGEXP 或 RLIKE，不要直接把它们的历史结果当成 REGEXP_LIKE() 的保证。MySQL 文档还特别提醒，旧的正则运算符存在多字节字符集限制；升级时应重新跑中文样例，而不是只比较 SQL 文本。

相关问题

改了数据库默认排序规则，为什么 REGEXP_LIKE 仍然不变？

数据库默认值只影响未被更具体层级覆盖的对象；列定义、连接设置、字面量字符集和表达式级 COLLATE 都可能继续生效。用 INFORMATION_SCHEMA.COLUMNS、系统变量和 COLLATION() 实测。

中文匹配应该选 _ci 还是 _cs？

如果模式中的英文大小写需要视为同一类，选不区分大小写的规则或显式使用 i；如果要严格区分，选 _cs 或显式使用 c。中文业务仍应以代表性数据回归，而不要只凭后缀做判断。

迁移清单

• 确认列和连接都使用 utf8mb4，不要新增依赖已弃用 utf8mb3 的写法。
• 两端显式统一 COLLATE，并记录选择该规则的业务原因。
• 把 c、i、NULL、混合中英文加入回归样例。
• 旧 REGEXP/RLIKE 迁移到 REGEXP_LIKE() 时重新验证多字节中文输入。