lenGTH返回字节数，CHAR_Length返回字符数；在utf8mb4下中文、emoji等多字节字符导致两者结果不同，业务校验必须用CHAR_LENGTH避免静默错误。
LENGTH 和 CHAR_LENGTH 返回值为什么不一样
mysql 里 LENGTH() 返回字节数，CHAR_LENGTH() 返回字符数，两者在多字节字符集（比如 utf8mb4）下必然不同。比如一个中文汉字在 utf8mb4 下占 3 个字节，LENGTH('好') 得 3，CHAR_LENGTH('好') 得 1。
常见错误现象：用 LENGTH() 判断昵称是否超 10 个字符，结果用户输两个 emoji 就触发截断——因为单个 ? 占 4 字节，LENGTH('??') = 8，但实际是 2 个字符，已超长。
- 判断「用户输入长度限制」必须用
CHAR_LENGTH() - 做底层存储估算（比如计算 VARCHAR 实际占用字节数）才看
LENGTH() - 若字段是 latin1 或 ASCII 编码，两者结果一致，但别依赖这点——上线后改字符集就翻车
utf8mb4 下 emoji 和生僻字让 LENGTH 突然变大
utf8mb4 支持 4 字节字符（如大部分 emoji、部分 CJK 扩展汉字），这时 LENGTH() 可能远大于 CHAR_LENGTH()。例如 LENGTH('??') 是 11（含零宽连接符），而 CHAR_LENGTH('??') 是 1。
使用场景：日志字段截断、导出 CSV 字段对齐、生成固定宽度报表时，如果按 LENGTH() 截取，可能切在 emoji 中间，导致乱码或解析失败。
- 导出前统一用
SUBSTRING(str, 1, 20)+CHAR_LENGTH()控制字符数，别用LEFT(str, 20) - 建表时 VARCHAR(255) 的 255 指字符数，不是字节数；但 InnoDB 行最大限制看的是字节数，所以 utf8mb4 下一行最多存约 65535 / 4 ≈ 16383 字符（还得扣掉其他字段开销）
- ORDER BY 或 GROUP BY 中用
LENGTH()排序毫无业务意义，容易误以为“短字符串排前面”，实际是“字节少的排前面”
WHERE 条件里用 LENGTH 做模糊过滤很危险
写 WHERE LENGTH(title) > 50 看似合理，但如果 title 是 utf8mb4 字段，这个条件实际筛的是「字节数超 50 的记录」，可能漏掉大量长中文标题（比如 17 个汉字就超 50 字节），也可能误抓一堆短 emoji 组合。
性能影响：该条件无法走索引（除非你建了函数索引，且 MySQL ≥ 8.0.13），全表扫描概率高；更糟的是语义偏差会引发线上查询结果不符合产品预期。
- 需要按「字符长度」过滤，明确写
CHAR_LENGTH(title) > 50 - 如果真要按字节控制（如协议层包体限制），请在应用层处理，SQL 层尽量不暴露字节逻辑
- 注意：MySQL 5.7 不支持函数索引，
CHAR_LENGTH(title)无法索引，大数据量时考虑冗余一个title_char_len字段并维护它
从 SQL Server 或 postgresql 迁移时容易忽略的兼容点
SQL Server 的 LEN() 等价于 MySQL 的 CHAR_LENGTH()，PostgreSQL 的 length() 默认也是字符数——所以直接把 LEN(title) > 50 改成 MySQL 的 LENGTH(title) > 50 就会出错。
另一个坑：某些 ORM（如旧版 django）生成的 SQL 会默认用 LENGTH()，但开发者以为它返回字符数，结果在中文环境上线后才发现长度校验失效。
- 跨数据库迁移时，逐个检查所有涉及字符串长度的 SQL，把
LENGTH替换为CHAR_LENGTH（除非你确认要字节语义） - 在 MySQL 配置中设
sql_mode=STRICT_TRANS_TABLES,NO_ZERO_DATE,NO_ZERO_IN_DATE并开启character_set_server=utf8mb4，避免隐式降级成 latin1 导致长度误判 - 测试用例里必须包含中文、emoji、混合中英文的字符串，只测 ‘abc’ 和 ‘测试’ 不够——‘??好’这种组合才能暴露出字节/字符混淆问题
字符集和长度函数的耦合比想象中深，哪怕表结构和数据看着没问题，一个没注意的函数选错，就可能让前端显示截断、后台校验绕过、导出文件损坏——这些都不是报错，而是静默错。