如何通过Length与CharLength区分查看MySQL字段占用存储空间的方法？

本文共计908个文字，预计阅读时间需要4分钟。

MySQL中的`LENGTH()`和`CHAR_LENGTH()`函数都可以用来查询字段的长度，但它们计算方式不同。`LENGTH()`按字节计算，而`CHAR_LENGTH()`按字符计算。对于ASCII字符（如英文、数字），两者结果相同；但对于中文、emoji或带重音符号的字符（如é、ñ），由于它们占用多个字节，`CHAR_LENGTH()`的结果会比`LENGTH()`多几倍。

常见错误现象：用 LENGTH() 判断 VARCHAR(255) 是否超长，结果插入失败或被截断——因为字段定义的是“字符数上限”，而你用字节长度去比对。

• LENGTH('你好') 返回 6（UTF8MB4 下每个汉字占 3 字节）
• CHAR_LENGTH('你好') 返回 2（就是 2 个字符）
• 建表时 VARCHAR(10) 表示最多存 10 个字符，不是 10 字节

查某条记录里某个字段实际占多少字节：用 LENGTH()

想评估磁盘占用、排查行溢出（如 InnoDB 的页内存储限制）、分析 BLOB/TEXT 字段体积，必须用 LENGTH()。它反映真实存储开销。

例如查用户昵称字段的字节占用分布：

SELECT id, nickname, LENGTH(nickname) AS byte_size, CHAR_LENGTH(nickname) AS char_count FROM users WHERE nickname IS NOT NULL ORDER BY byte_size DESC LIMIT 10;

注意：如果字段是 TEXT 或启用了 ROW_FORMAT=COMPRESSED，实际物理存储还受页压缩、外部存储等因素影响，LENGTH() 只给出逻辑字节长度。

判断字段是否超出定义长度：必须用 CHAR_LENGTH()

MySQL 内部校验字段长度上限（比如 VARCHAR(50)）依据的是字符数，不是字节数。所以业务层做前置校验、日志告警、ETL 数据清洗时，该用 CHAR_LENGTH()。

• 错误写法：WHERE LENGTH(title) > 100 → 可能放过一个 34 个汉字（102 字节）的超长标题
• 正确写法：WHERE CHAR_LENGTH(title) > 100
• 在触发器或存储过程中做截断，也要用 LEFT(col, 100)（它按字符截），而不是 SUBSTR(col, 1, 100)（默认按字节，行为依赖 character_set_client）

utf8mb4 下 emoji 和生僻字会让 LENGTH 突然翻倍

UTF8MB4 字符集下，普通汉字仍是 3 字节，但 emoji（如 ?、?‍?）和部分 CJK 扩展区汉字（如「?」）占 4 字节。这意味着同样 10 个字符的字段，LENGTH() 可能在 30～40 字节之间浮动。

容易踩的坑：

• 建表时只按平均字节数估算行大小，忽略 4 字节极端情况，导致单行超过 8000 字节，InnoDB 强制转为溢出页存储，性能下降
• 使用 GROUP_CONCAT() 拼接含 emoji 的字段，没设足够大的 group_concat_max_len，结果被无声截断
• 应用层用 Java 的 String.getBytes().length（默认平台编码）对比 MySQL 的 LENGTH()，结果不一致——务必统一指定 UTF-8 编码

真正影响存储和索引效率的是字节长度，但语义约束和可读性依赖字符长度。这两个函数不是选一个“更好”，而是各自守住自己的边界。漏掉任一维度，都可能在线上突然冒出截断、告警、慢查询。