MySQL匹配中文需用双反斜杠\u且字段collation必须为utf8mb4_unicode_ci等支持Unicode的规则，否则REGEXP静默失效；PostgreSQL用~操作符更稳，SQL Server则依赖LIKE+N''+SC_UTF8排序规则。
MySQL用REGEXP匹配中文必须转义u且依赖排序规则
直接写 name REGEXP '[u4e00-u9fa5]' 在 MySQL 8.0+ 里看似能跑，但实际可能静默失效——根本原因不是语法错，而是 utf8mb4_general_ci 这类旧 collation 不支持 Unicode 码点范围比较。
真正生效的写法是：
SELECT * FROM users WHERE name REGEXP '[\u4e00-\u9fa5]';
注意两点：
-
\u是 SQL 字符串里的双反斜杠，最终被解析为单个u交给正则引擎 - 表或字段必须使用
utf8mb4_unicode_ci或utf8mb4_0900_as_cs等支持 Unicode 属性的 collation，否则范围匹配不触发 - 别用
[一-龥]：它在 MySQL 里会被当作字面字符集处理，而非 Unicode 区间，覆盖不全还容易漏字
PostgreSQL用~操作符更稳，但别加E''前缀
PostgreSQL 的 ~ 是原生 POSIX 正则接口，对 Unicode 范围支持直接，不受 collation 干扰，推荐写法：
SELECT * FROM products WHERE title ~ '[u4e00-u9fff]';
常见踩坑点：
- 写成
title ~ E'[u4e00-u9fff]'反而报错——E''是 PostgreSQL 的转义字符串字面量，但~已内置 Unicode 解析，重复转义会破坏格式 -
u9fff比u9fa5更全，覆盖了扩展 A/B 区汉字（如「?」「?」） - 字段为
NULL时整行被过滤，需显式补AND title IS NOT NULL
SQL Server不用正则，LIKE + N'' + COLLATE 才可靠
SQL Server 2016+ 不支持 Unicode 正则，但 LIKE 配合正确声明可精准匹配中文区间：
SELECT * FROM logs WHERE content LIKE N'%[一-鿿]%' COLLATE Latin1_General_100_CI_AS_SC_UTF8;
三个硬性条件缺一不可：
- 必须用
N''前缀声明 Unicode 字符串，否则中文范围被当乱码处理 -
COLLATE必须指定以_SC_UTF8结尾的排序规则（如Latin1_General_100_CI_AS_SC_UTF8），Chinese_PRC_CI_AS这类老规则只按拼音排序，不认码点 -
一-鿿是目前最全的汉字区间（U+4E00–U+9FFF + U+3400–U+4DBF + U+20000–U+2A6DF），比单纯一-龥多覆盖数千字
跨库兜底方案：LENGTH() ≠ CHAR_LENGTH() 仅适用于 UTF-8 存储
当没权限用正则、或数据库版本太老时，可用字节长度差粗筛中文：
SELECT * FROM comments WHERE LENGTH(content) != CHAR_LENGTH(content);
原理和限制都很明确：
- 在 UTF-8 下，ASCII 字符占 1 字节，中文占 3 字节，所以
LENGTH()（字节长） >CHAR_LENGTH()（字符数）即大概率含中文 - 误判率高：emoji、全角标点、某些符号也占多字节，无法区分
- 仅限 UTF-8 环境；若库用 GBK/UTF-16，该方法完全失效
- MySQL 中
length()和char_length()名称固定，SQL Server 用DATALENGTH()和LEN()，函数名不能混用
真正难的不是写出某条语句，而是确认当前字段的 collation、字符集、以及数据库版本是否支持你写的那个 Unicode 写法。很多“明明语法对却没结果”的问题，都卡在 collation 这一层。
