必须用CHAR_LENGTH()，因LENGTH()返回字节数而非字符数，utf8mb4下中文、emoji等多字节字符会导致长度误判；CHAR_LENGTH()按Unicode字符计数，与前端一致，适用于所有语言校验。

LENGTH 返回字节数，不是字符数

这是最常踩的坑：你写 WHERE LENGTH(name) > 10，本意是拦住“超过10个汉字”的用户名，结果发现“你好?”（2个汉字+1个emoji）就触发了——因为 LENGTH('你好?') 在 utf8mb4 下通常是 10（“你好”各3字节 + emoji占4字节），而它明明只有3个字符。
这种错位在和前端对齐时尤其明显：JS 的 str.length 数的是 Unicode 字符，MySQL 的 LENGTH() 数的是字节，直接对比必出问题。
常见错误现象包括：
• 用户名校验逻辑失效（比如限制10字符，实际存了7个汉字+1个emoji就被截断）
• 短信内容计数不准，导致超长未预警
• 备份还原后因字符集变更（如从 latin1 切到 utf8mb4），LENGTH() 结果翻倍，原有 WHERE 条件行为突变

CHAR_LENGTH 才是你日常该用的“字符数”

CHAR_LENGTH() 按 Unicode 码点计数，一个汉字、一个英文字母、一个 emoji 都算 1。它不依赖字符集，结果稳定，和 Python 的 len()、JS 的 .length 行为一致。
适用场景非常明确：
• 用户输入长度限制（如 CHAR_LENGTH(username) ）<br>• 标题/昵称/短信内容字符统计<br>• JSON 字段里字符串长度校验（JSON 规范按字符计）<br>• 判断字段是否含中文：<code>LENGTH(col) != CHAR_LENGTH(col) 可作为快速筛选条件（前提是字符集为多字节）

什么时候必须用 LENGTH？

只有两类情况绕不开 LENGTH()：
• 计算真实存储开销，比如判断某 VARCHAR(255) 字段是否接近物理上限（utf8mb4 下最多存 63 个 4 字节 emoji）
• 做协议层字节级截断，例如 HTTP header 或二进制协议 payload 有严格字节限制
注意：LENGTH() 结果随连接字符集变化，执行前务必确认当前会话字符集：SELECT @@character_set_client;；否则 SET NAMES utf8mb4 未生效时，结果可能与预期不符

索引和性能影响不能忽略

无论用 LENGTH(col) > 10 还是 CHAR_LENGTH(col) > 10，只要函数作用于字段，MySQL 就无法直接走索引——它得对每一行先算一遍长度。
如果业务真要高频按长度过滤，别硬扛：
• 加生成列：ALTER TABLE users ADD COLUMN name_char_len TINYINT AS (CHAR_LENGTH(name)) STORED，再给它建索引
• 或者业务层入库时就计算并存到独立字段（如 name_length），避免查询时实时计算
跨数据库迁移更要小心：PostgreSQL 的 LENGTH() 等价于 MySQL 的 CHAR_LENGTH()，SQL Server 的 LEN() 也是字符数，但 Oracle 的 LENGTH() 默认是字符数、LENGTHB() 才是字节数——直接复制 SQL 很容易翻车