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 之前先想清楚业务要什么。
