用 CHAR_LENGTH() 获取字符串的字符数，不是字节数；它在 MySQL、PostgreSQL、SQLite 中行为一致，但 SQL Server 用 LEN() 且会截断末尾空格。
CHAR_LENGTH 函数怎么用？
直接回答：用 CHAR_LENGTH() 获取字符串的字符数，不是字节数。它在 MySQL、PostgreSQL、SQLite 等主流数据库里都支持，行为一致；但注意 SQL Server 用的是 LEN()，且会自动截断末尾空格——这点最容易踩坑。
常见错误现象是：明明字符串末尾有空格，CHAR_LENGTH() 返回值却比预期少——那基本是你误用了 LENGTH()（返回字节数）或跑在 SQL Server 上用了 LEN()。
-
CHAR_LENGTH('abc ')→ 返回4（含末尾空格） -
LENGTH('abc ')在 UTF8mb4 下也返回4，但'你好 '会返回7（3 字符 × 3 字节 + 1 空格），不可靠 - MySQL 中
CHAR_LENGTH()和CHARACTER_LENGTH()完全等价，后者是标准 SQL 写法，可读性略好
为什么不能用 LENGTH() 替代？
因为 LENGTH() 返回的是字节数，不是字符数。在多字节字符集（如 utf8mb4）下，一个汉字占 3 或 4 字节，LENGTH() 就会严重高估“长度感”。业务上判断用户名是否超 20 个字符，用 LENGTH() 可能让一个 10 字中文名就报错。
- 场景：校验用户昵称 ≤ 12 字符，数据库字符集为
utf8mb4 - 错误写法：
WHERE LENGTH(nickname) > 12→ 实际可能只写了 4 个汉字就触发 - 正确写法：
WHERE CHAR_LENGTH(nickname) > 12 - 兼容提示：PostgreSQL 的
LENGTH()行为等同于 MySQL 的CHAR_LENGTH()，属于特例，别凭经验套用
在 WHERE / ORDER BY / SELECT 中怎么安全使用？
CHAR_LENGTH() 是标量函数，可以放心用于过滤、排序和投影，没有隐式类型转换风险，也不影响索引使用——但注意：对字段套函数后无法走索引，比如 WHERE CHAR_LENGTH(name) = 5 无法利用 name 上的索引。
- 能走索引的写法：
WHERE name LIKE '_____'（5 个下划线），前提是确定字符集单字节且无变长问题 - 排序示例：
ORDER BY CHAR_LENGTH(title) DESC, title—— 先按长度排，长度相同时按字典序 - SELECT 中常用：
SELECT title, CHAR_LENGTH(title) AS len FROM posts，适合做长度分布统计 - 性能提醒：在大表上
SELECT CHAR_LENGTH(col)不会拖慢查询，但WHERE CHAR_LENGTH(col) > N会强制全表扫描
CHAR_LENGTH 处理 NULL 和空字符串的区别
CHAR_LENGTH(NULL) 返回 NULL，不是 0；而 CHAR_LENGTH('') 明确返回 0。这个差异直接影响 WHERE 条件和聚合结果，尤其在统计“非空但有内容”的字段时容易漏掉 NULL 行。
- 错误统计：
COUNT(CHAR_LENGTH(content))会把NULL当作一行计入（因为COUNT()统计非 NULL 值），但实际想统计的是“有内容的行” - 正确写法：
COUNT(CASE WHEN content IS NOT NULL AND CHAR_LENGTH(content) > 0 THEN 1 END) - 简化技巧：MySQL 支持
IFNULL(CHAR_LENGTH(content), 0)，但 PostgreSQL 要用COALESCE(CHAR_LENGTH(content), 0)
最常被忽略的一点：很多人以为 CHAR_LENGTH() 会把 NULL 转成 0，结果在条件判断里写 CHAR_LENGTH(x) > 0 却漏掉了所有 NULL 值——它根本不会进这个分支，因为 NULL > 0 是 UNKNOWN，不满足 WHERE 条件。
