MySQL中匹配中文应使用REGEXP '[\u4e00-\u9fa5]'（双反斜杠转义），且需utf8mb4_unicode_ci等Unicode排序规则；PostgreSQL用~ '[u4e00-u9fff]'更稳定；SQL Server需LIKE N'%[一-鿿]%' COLLATE ..._SC_UTF8。
MySQL中用REGEXP匹配中文字符的正确写法
MySQL 8.0+ 默认支持Unicode正则，但REGEXP直接写[一-龥]会失效——因为MySQL的字符集排序规则（collation）影响范围匹配行为，不是编码问题，而是比较逻辑问题。
实际生效的写法是：
SELECT * FROM users WHERE name REGEXP '[\u4e00-\u9fa5]';
注意两点：
• 必须用双反斜杠\u（SQL字符串转义后变成单u）
• 仅在utf8mb4_unicode_ci或utf8mb4_0900_as_cs等支持Unicode排序规则下可靠
• utf8mb4_general_ci（旧默认）不支持Unicode属性匹配，会静默失败
PostgreSQL里用~操作符检测中文更稳定
PostgreSQL的~操作符底层调用的是POSIX正则引擎，对Unicode范围支持更直接，且不受collation干扰。
推荐写法：
SELECT * FROM products WHERE title ~ '[u4e00-u9fff]';
常见误用点：
• 写成~ E'[\u4e00-\u9fff]'反而错误——E''是转义字符串字面量，但~本身已解析Unicode转义
• 若字段可能为NULL，需额外加AND title IS NOT NULL，否则整行被过滤掉
• u9fff比u9fa5覆盖更全（含扩展A/B区汉字）
SQL Server不用正则，改用LIKE + Unicode范围
SQL Server 2016+ 不支持Unicode正则，但LIKE可配合N'前缀和字符范围工作：
SELECT * FROM logs WHERE content LIKE N'%[一-鿿]%' COLLATE Latin1_General_100_CI_AS_SC_UTF8;
关键约束：
• 必须用N'...'声明Unicode字符串
• COLLATE必须显式指定_SC_UTF8结尾的排序规则（否则中文范围无效）
• 一-鿿是较全的汉字区间（U+4E00–U+9FFF + U+3400–U+4DBF + U+20000–U+2A6DF），比单纯一-龥更准
• 千万别用Chinese_PRC_CI_AS——它只按拼音排序，不支持Unicode码点范围
跨数据库通用但低效的兜底方案：LEN() vs DATALENGTH()
当正则不可用或权限受限时，可用字节长度差判断是否含中文（假设数据库用UTF-8/UTF-16存储）：
例如MySQL：
SELECT * FROM comments WHERE LENGTH(content) != LENGTH(CONVERT(content USING latin1));
原理：
• 中文字符在UTF-8下占3字节，在latin1下会被截断为1字节（乱码但长度可比）
• 这种方式不精确（可能误判emoji、全角标点），但无正则权限时能快速筛出“大概率含中文”的记录
• PostgreSQL需改用OCTET_LENGTH(content)对比CHAR_LENGTH(content)
• SQL Server用DATALENGTH(content)对比LEN(content)
真正难处理的是混合场景：字段同时含中日韩越汉字、古籍生僻字、以及CJK统一汉字扩展G区（U+31300起）——这时候正则范围得手动补全，而多数业务其实只需识别常用字，别一上来就堆最大范围。
