PostgreSQL中~区分大小写、~*不区分，MySQL正则不支持\d等简写需改用[0-9]，SQL Server原生无正则仅LIKE，调试推荐REGEXP_REPLACE直观验证匹配位置。
PostgreSQL 的 ~ 和 ~* 别写反了
大小写敏感是默认行为，~ 匹配区分大小写，~* 才不区分。很多人写 WHERE name ~ 'abc' 想找 "ABC" 或 "Abc"，结果查不到——不是正则写错了，是忘了加星号。
- 测试时先用
SELECT 'ABC' ~* 'abc'确认基础行为 - 线上查询别依赖隐式转换，显式写
~*或ILIKE（后者不支持复杂正则但更直观） -
!~和!~*是取反操作，注意逻辑翻转后是否符合业务预期
MySQL 8.0+ 的 REGEXP_LIKE() 不支持 \d 这类简写
MySQL 的正则引擎基于 ICU，但对 POSIX 字符类支持有限。\d、\w、\s 在部分版本里直接报错或行为异常，必须改写成 [0-9]、[a-zA-Z0-9_]、[[:space:]]。
- 错误现象：
SELECT '123' REGEXP '\d{3}'返回NULL或0，而非预期的1 - 安全写法：
SELECT '123' REGEXP '^[0-9]{3}$'，开头结尾锚定避免子串误匹配 - 性能提示：不用
^和$时，MySQL 可能全表扫描做子串匹配，尤其字段没索引
SQL Server 的 LIKE 不是正则，别硬套 .*
SQL Server 原生不支持 PCRE 或 POSIX 正则，LIKE 只有 %（任意长）、_（单字符）、[abc] 这三种通配符。写 WHERE name LIKE 'a.*b' 会当字面量匹配，根本不会解释 .*。
- 想实现正则需启用 CLR 集成或调用外部函数，代价高；轻量场景优先用
CHARINDEX()+SUBSTRING()组合判断 -
LIKE 'a%b'和LIKE 'a_b'能走索引，但LIKE '%a%'不能——前导通配符等于放弃索引 - 如果真要正则，确认 SQL Server 版本 ≥ 2017 且已开启
sp_configure 'show advanced options', 1和'clr enabled', 1，再部署自定义函数
调试时用 REGEXP_REPLACE() 看匹配位置比 REGEXP_LIKE() 更直观
光知道“匹配成功”不够，常需要确认到底哪部分被命中。PostgreSQL 和 MySQL 8.0+ 都支持 REGEXP_REPLACE()，把匹配内容替换成带标记的字符串，一眼看出捕获逻辑是否正确。
- 示例：
SELECT REGEXP_REPLACE('price: $123.45', '(\$\d+\.\d+)', '[MONEY:$1]')→price: [MONEY:$123.45] - 分组捕获数不清？用
REGEXP_SUBSTR()（MySQL）或substring()（PostgreSQL）单独抽某组验证 - 注意空匹配陷阱：某些正则如
a*在字符串开头可能匹配空字符串，导致替换出一堆标记，先加+或{1,}限定至少一次
正则在 SQL 里没法像应用层那样打断点、看变量值，所有调试都得靠“输出可观测”。最省事的方式，其实是把待测数据和正则表达式一起塞进 SELECT 里反复跑，而不是先写进 WHERE 再猜为什么没结果。
