MySQL 8.0+用REGEXP_LIKE(name, '[u4e00-u9fa5]')匹配中文，需字段字符集为utf8mb4；老版本可用LENGTH(col)!=CHAR_LENGTH(col)间接判断；PostgreSQL推荐name ~ 'p{Han}'；SQL Server用LIKE '%[一-龥]%' COLLATE Chinese_PRC_CI_AS。
用正则表达式匹配中文字符（MySQL 8.0+）
MySQL 8.0 开始原生支持 REGEXP_LIKE()，判断字段是否含中文最直接的方式就是匹配 Unicode 中文范围：[u4e00-u9fa5]。注意：必须确保字段字符集为 utf8mb4，否则可能匹配失败或漏判。
实操建议：
- 确认表字段编码：
SHOW CREATE TABLE your_table;，检查列定义是否含CHARACTER SET utf8mb4 - 基础查询写法：
SELECT * FROM users WHERE REGEXP_LIKE(name, '[\u4e00-\u9fa5]');（注意反斜杠要双写） - 若需兼容全角标点、平假名、片假名等，可扩展为
[\u4e00-\u9fff\u3400-\u4dbf\u3040-\u309f\u30a0-\u30ff] - 性能提示：该条件无法使用索引，大数据量时慎用在
WHERE主过滤条件中
MySQL 5.7 及更早版本的替代方案
老版本不支持 Unicode 正则，只能靠字节长度 + ASCII 判定间接识别：中文字符在 utf8mb4 下占 3–4 字节，而纯 ASCII 字符（字节值 LENGTH() 和 CHAR_LENGTH() 差值判断是否存在多字节字符。
实操建议：
-
LENGTH(col)返回字节数，CHAR_LENGTH(col)返回字符数；若二者不等，说明含非 ASCII 字符（包括中文、emoji、日文等） - 较严格的中文筛选（排除 emoji）：
WHERE LENGTH(col) != CHAR_LENGTH(col) AND col REGEXP '[a-zA-Z0-9[:punct:]\s]*'不推荐——正则仍不可靠 - 更稳妥做法：在应用层清洗，或升级 MySQL 版本
- 注意：
CONVERT(col USING gbk)等转换方式极易出错，不建议用于判断
PostgreSQL 中判断中文的正确写法
PostgreSQL 原生支持 Unicode 属性类正则，用 ~ 操作符配合 p{Han} 最准确——它专指汉字（Han script），不包含日文平假名、韩文等。
实操建议：
- 直接写法：
SELECT * FROM users WHERE name ~ 'p{Han}'; - 如需大小写不敏感，用
~*；想排除空格干扰，先TRIM(name) - 确保数据库编码为
UTF8（建库时指定），否则p{Han}会失效 - 性能上，可对表达式建函数索引：
CREATE INDEX idx_name_han ON users ((name ~ 'p{Han}'));
SQL Server 使用 COLLATE 处理中文判断
SQL Server 不支持 Unicode 脚本类正则，但可通过排序规则（collation）和字符范围比较实现。关键点是：中文字符在常用 Unicode 排序规则（如 Chinese_PRC_CI_AS）下有明确的码位区间。
实操建议：
- 简单范围判断（适用于简体中文主流字）：
WHERE name LIKE '%[吖-咗]%' COLLATE Chinese_PRC_CI_AS - 更全的覆盖可拼接多个区间：
LIKE '%[一-龥]%' COLLATE Chinese_PRC_CI_AS（龥是 Unicode 末尾常用汉字） - 注意：
COLLATE子句必须显式写出，否则默认排序规则可能不识别中文范围 - 该方式无法识别生僻字或扩展 B 区汉字（U+3400–U+4DBF），且
LIKE无法走索引，大数据慎用
中文字符判断看似简单，真正落地时最常被忽略的是字符集与排序规则的一致性——哪怕正则写对了，utf8mb4 表配 latin1 连接，结果全是乱码匹配。先查 SHOW VARIABLES LIKE 'character_set%'; 和 SELECT COLLATION_NAME FROM INFORMATION_SCHEMA.COLUMNS，比调正则花的时间还多。
