MySQL中REGEXP匹配中文失效主因是字符集未设为utf8mb4、REGEXP按字节工作不支持多字节安全匹配，且5.7版本不支持u4e00等Unicode简写；UPDATE时需先用SELECT验证正则是否命中，再加LIMIT测试更新。
MySQL中用REGEXP匹配并UPDATE时为什么没生效
直接在UPDATE语句里写WHERE column REGEXP 'pattern'是可行的，但常见失效原因不是语法错，而是正则引擎行为差异——MySQL 5.7默认用的是基本正则（BRE），不支持+、?、d等简写；MySQL 8.0+才默认启用RE2，支持更现代的语法。若你用的是5.7且写了'd{3}-d{4}'，实际会被当字面量匹配，根本不会识别d。
实操建议：
- 先用
SELECT * FROM table WHERE column REGEXP '^1[3-9]\d{9}$'验证是否真能捞出目标行（注意双反斜杠：MySQL字符串解析会吃掉一层） - MySQL 5.7中避免用
sw，改用字符组，比如[[:space:]]或[a-zA-Z0-9_] - 更新前务必加
LIMIT测试，例如UPDATE t SET status='done' WHERE phone REGEXP '^[1][3-9][0-9]{9}$' LIMIT 3
PostgreSQL里想批量替换邮箱域名，用~和REGEXP_REPLACE怎么配对
PostgreSQL不用REGEXP关键字做条件判断，而是用~操作符（区分大小写）或~*（不区分）。真正做文本替换得靠REGEXP_REPLACE()函数，它不能直接写在SET右边当表达式用，必须显式调用。
常见错误是写成SET email = email ~ '.*@old.com' THEN REGEXP_REPLACE(...)——这是语法错误，PostgreSQL不支持这种内联条件替换。
正确写法：
UPDATE users SET email = REGEXP_REPLACE(email, '@old.com$', '@new.com', 'g') WHERE email ~ '@old.com$';
说明：
-
'g'标志必须加，否则只换第一个匹配（即使邮箱里有多个@，也只动末尾那个） - 域名里的点号
.要转义成.，否则正则会当成“任意字符” -
WHERE子句用~快速过滤，避免对全表执行REGEXP_REPLACE（后者开销大）
SQL Server没有REGEXP，用LIKE模拟手机号匹配风险在哪
SQL Server至今不原生支持正则，LIKE是唯一选择，但它的通配符能力极弱：[0-9]只能匹配单字符，无法表达“连续11位数字”。硬凑LIKE '[1][3-9][0-9][0-9][0-9][0-9][0-9][0-9][0-9][0-9][0-9]'看似可行，实则隐患很多：
- 长度不可控：如果字段存了空格或短横线（如
'138-1234-5678'），LIKE完全无能为力 - 无法排除字母：像
'138abc12345'也会被[0-9]段匹配上 - 性能差：索引对
LIKE前导通配符（如LIKE '%138%'）完全失效
更稳妥的做法是结合LEN()和LEFT()初步筛，再用CLR正则函数（需DBA开启）或迁移到应用层处理。临时方案可加计算列：ALTER TABLE users ADD phone_clean AS REPLACE(REPLACE(phone, '-', ''), ' ', '')，再对phone_clean用LIKE。
Oracle中REGEXP_LIKE和REGEXP_REPLACE更新时字符集引发的乱码
Oracle正则函数对字符集敏感。如果你的数据库是AL32UTF8，但客户端NLS设置是WE8MSWIN1252，执行REGEXP_LIKE(name, '张.*') 可能返回空结果——不是正则写错，而是“张”字在客户端被错误解码，传到服务端已变。
排查步骤：
- 查当前会话字符集：
SELECT SYS_CONTEXT('USERENV','NLS_CHARACTERSET') FROM DUAL; - 确认客户端与服务端一致，否则在
UPDATE前显式转换：REGEXP_REPLACE(UTL_RAW.CAST_TO_NVARCHAR2(name), '旧.*', '新') - 避免在
REGEXP_REPLACE中使用中文量词如{2,}，Oracle对Unicode字符计数有时不准，改用{1,10}加LENGTH()二次校验更稳
跨库迁移正则逻辑时，最容易被忽略的是转义层级和字符集隐式转换——同一段REGEXP_REPLACE(text, 's+', ' ')在MySQL、PostgreSQL、Oracle里，实际执行的空白符范围可能完全不同。
