SQL字符串长度计算LENGTH与CHAR_LENGTH用法

在数据库开发中，处理字符串长度时，有一个特别容易踩的坑：LENGTH 和 CHAR_LENGTH 这两个函数，表面看都是算“长度”，实际上一个算的是字节数，一个算的是字符个数。尤其当字段里存的是中文、emoji 或者用 utf8mb4 编码的内容时，两者的差异能直接导致业务逻辑出错。比如一个汉字在 utf8mb4 下占 3 或 4 个字节，LENGTH 会返回 3 或 4，而 CHAR_LENGTH 始终返回 1 —— 如果你要校验“用户输入不能超过10个字符”，就必须用 CHAR_LENGTH，否则用户只打3个汉字就可能被 LENGTH 误判为超长。只有做底层字节截断（比如适配老旧协议的字节限制）时，才应该用 LENGTH。

LENGTH 和 CHAR_LENGTH 在 MySQL 中到底有什么区别？

直接说结论：LENGTH 返回字节数，CHAR_LENGTH 返回字符个数。在 utf8mb4 编码下，一个中文汉字占 3 或 4 字节，一个 emoji 表情占 4 字节，所以 LENGTH('中') 是 3 或 4，CHAR_LENGTH('中') 是 1。这个差异在业务校验中尤其致命。

• 如果你要校验用户输入是否超过「10 个字符」，必须用 CHAR_LENGTH，否则中文输 3 个字就可能触发 LENGTH > 10
• 如果你在做底层字节截断（比如适配旧协议限制），才考虑 LENGTH
• 在 utf8mb4 + emoji 场景下，一个 ? 的 LENGTH 是 4，CHAR_LENGTH 是 1

PostgreSQL 和 SQL Server 怎么办？没有 CHAR_LENGTH？

不同数据库的函数命名和默认行为差异很大。PostgreSQL 只有一个 LENGTH，但它默认按字符计数——行为等价于 MySQL 的 CHAR_LENGTH，所以可以直接用。SQL Server 的 LEN 也按字符算，但有一个容易忽略的细节：它会自动忽略末尾空格。比如 LEN('abc ') 返回 3，要想得到 6 个字节数，得用 DATALENGTH('abc ')。注意 DATALENGTH 返回的是字节数，不是字符数。

• PostgreSQL：LENGTH('你好') → 2，安全可用
• SQL Server：LEN('abc ') → 3，要用 DATALENGTH('abc ') 才得 6（字节数），且注意 DATALENGTH 返回的是字节数，不是字符数
• 跨数据库写法？别硬套函数名，先确认目标库的文档里该函数定义是「字符」还是「字节」

WHERE 条件里用 LENGTH/CHAR_LENGTH 性能很差？

确实如此。在大表上对字段套 CHAR_LENGTH(name) > 10 基本无法走索引——MySQL 无法为函数结果建立普通 B+Tree 索引（除非用生成列 + 索引）。如果业务里有类似“查询字符长度大于10的记录”这种需求，更好的做法是提前设计好存储结构。

• 更高效的做法：加一个 name_length TINYINT UNSIGNED AS (CHAR_LENGTH(name)) STORED 生成列，再给它建索引
• 或者业务层控制：插入前就计算并存入 name_len 字段，查询直接用 name_len > 10
• 临时查？可以接受全表扫描时再用，但别放在高频查询的 WHERE 里

遇到 NULL 或 TEXT 字段时要注意什么？

空值很容易被忽略。记住：CHAR_LENGTH(NULL) 返回 NULL，不是 0。如果你判断空字符串只写了 CHAR_LENGTH(col) = 0，当 col 为 NULL 时这个条件永远假，会漏掉数据。正确写法是 CHAR_LENGTH(col) IS NULL OR CHAR_LENGTH(col) = 0，或者用 COALESCE(CHAR_LENGTH(col), 0) 统一转成数字。

对 TEXT 类型字段调用 CHAR_LENGTH 本身没问题，但某些老版本 MySQL 对超长 TEXT（如 > 65535 字节）可能截断计算结果。如果字段类型是 MEDIUMTEXT 或 LONGTEXT，建议在应用层校验长度，避免数据库隐式转换开销。

最后啰嗦一句：到底用哪个函数，取决于你真正想量的是「人眼看到的字符个数」还是「存储占了多少字节」。这两个概念在多字节编码里从不相等，混淆它们是线上出 bug 的常见源头。别嫌麻烦，写 SQL 之前先想清楚业务要什么。