utf8mb4下a和汉字占几字节？一文讲透字符集与索引陷阱

有次帮同事处理线上报错客户端明明传了一个笑脸符号MySQL 却回了一句Incorrect string value: \xF0\x9F\x98\x80。第一反应当然是字符集问题改成 utf8mb4 之后报错消失了。但第二天另一个同事拿着LENGTH()的查询结果来问utf8mb4 下字母 a 占几个字节汉字占几个字节是不是改成 utf8mb4 后所有字符都变 4 字节了这个问题看着简单真说起来能一次性讲清楚的人不多。网上能搜到很多“a 占 1 字节汉字占 3 字节”的短答案但很少有人解释为什么 utf8mb3 和 utf8mb4 对汉字是一样的字节数也没人把由此引出的VARCHAR(191)、索引超长、表情符号存不进去这些连锁问题串起来。这篇想把这道题拆开讲透结论可以直接拿去用背后的原理也能让你下次被问的时候不慌。1. 先把三个概念拆开字符、字符集、编码1.1 字符集决定的是“哪个编号对应哪个字符”“字符集”这个名词在 MySQL 文档里被用得比较随意很多人把它理解成一张编码表其实严格说它包含两层含义一是给字符分配编号的规则二是把编号变成字节序列的规则。Unicode 字符集就是给字符分配编号的那一层它给每个字符分配一个唯一编号叫码点。比如字母a的码点是 U0061汉字“汉”的码点是 U6C49。这套编号是全世界通用的跟 MySQL 用什么字符集保存数据没有关系。真正有关系的是后面这层数据库拿到这个编号之后到底用几个字节、按什么规则存到磁盘上。弄混了这两层就会产生“Unicode 本身是不是固定两个字节”之类的误解。Unicode 是字符集不是编码方式它只负责告诉你“U6C49 就是汉字‘汉’”不负责规定存储形式。1.2 编码决定“编号在计算机里用几个字节表示”我们日常说的 UTF-8、UTF-16、UTF-32准确叫法是“编码方式”。同一个字符用不同编码方式得到的字节数可能完全不同。比如“汉”字在 UTF-8 编码下是 3 个字节在 UTF-16 编码下是 2 个字节在 GBK 编码下也是 2 个字节。字节数不是字符的天然属性而是编码方式决定的。MySQL 的 utf8mb4 采用的就是 UTF-8 编码核心特点是一个字符可能占 1 到 4 个字节不等属于变长编码。很多人以为“utf8mb4 是 4 字节编码所以汉字占 4 字节”这句话错在把最大字节数当成了固定字节数。编码方式只是规定了字节数范围并不是让每个字符都撑满上限。换句话说utf8mb4 能存 4 字节字符但不代表所有字符都按 4 字节存。1.3 MySQL 中的 utf8mb3 和 utf8mb4 到底是什么MySQL 里的utf8在 5.7 时代其实是不完整的 UTF-8一个字符最多只能占 3 个字节存不了码点超过 UFFFF 的字符比如表情符号或部分生僻字。后来为了和完整版区分MySQL 8.0 把它改叫utf8mb3。utf8mb4才是完整版的 UTF-8一个字符最多 4 字节。所以官方文档里常说“utf8mb4 是 utf8mb3 的超集”。在 MySQL 8.0 里默认字符集已经变成 utf8mb4但在老项目里依然能见到utf8或utf8mb3的配置。两者对字母和基本汉字的字节数没有任何区别区别只在于谁支持 4 字节字符。因此标题里的问题可以拆成两层一是编码层面理论上占几个字节二是 MySQL 这个字符集层面能不能存得下。2. 直接给结论a 和汉字在两种字符集下的真实字节数2.1 一张速查表先记住结果先回答标题本身。直接列出来字符utf8mb3 字节数utf8mb4 字节数说明字母 a11ASCII 范围内的字符永远 1 字节汉字“汉”33位于 Unicode 基本平面最多 3 字节中文标点如“”“。”33同样是基本平面内字符表情符号等补充平面字符无法存储4utf8mb3 会报错或变成乱码注意这里说的“汉字”指日常使用的 CJK 基本区汉字。如果遇到扩展区生僻字码点可能在 U20000 以上那它在 utf8mb4 下也需要 4 字节而 utf8mb3 不支持。这种情况在普通项目里很少遇到但严谨一点还是值得提。2.2 用两个 SQL 函数在命令行里实测MySQL 提供了LENGTH()返回字节数CHAR_LENGTH()返回字符数。这两个函数对比使用是验证字节数最直接的方法。实测时要注意连接字符集建议先执行SET NAMES utf8mb4;。下面是在 utf8mb4 下的结果SET NAMES utf8mb4; SELECT CHAR_LENGTH(a) AS char_len_a, LENGTH(a) AS byte_len_a; SELECT CHAR_LENGTH(汉) AS char_len_han, LENGTH(汉) AS byte_len_han;结果很明显a的字符数是 1字节数也是 1汉的字符数是 1字节数是 3。如果你想对表里的数据做批量验证可以这样写SELECT name, CHAR_LENGTH(name) AS chars, LENGTH(name) AS bytes FROM user WHERE name IN (a, 汉);LENGTH()的结果受两件事影响一是字符串本身的字符集二是返回给客户端的字符集。如果客户端连接字符集设置不对比如连接是latin1那汉这个字面量可能先被转成 latin1再算长度结果会变成 1 或 2。所以想确定列的真实尺寸建议配合SHOW CREATE TABLE或查information_schema来确认字段字符集。2.3 为什么“汉字在 utf8mb4 下占 4 字节”的说法是错的网上有个流传很广的说法utf8mb4 最大 4 字节所以汉字占 4 字节。这属于把字符集的最大字节数当成了每个字符的固定字节数。UTF-8 是变长编码码点在 U0080 到 U07FF 的字符占 2 字节码点在 U0800 到 UFFFF 的字符占 3 字节超过 UFFFF 的字符占 4 字节。绝大多数常用汉字的码点都落在 U4E00 到 U9FFF正好在 U0800 和 UFFFF 之间所以是 3 字节。那为什么 utf8mb4 这个名字里非要带个 4因为 MySQL 需要告诉存储层“这个列可能用到 4 字节的字符”于是长度计算和索引计算都要按 4 字节的最坏情况预留。但实际每个汉字仍然是 3 字节。这个“最坏情况预留”的机制会直接影响建表、索引和行长度下一章会专门展开。2.4 碰到生僻字时怎么判断它是 3 字节还是 4 字节日常汉字基本都是 3 字节但如果业务里要存古籍、人名生僻字、方言用字可能真的会遇到 4 字节汉字。判断方法很简单先看码点是否大于 UFFFF。可以用编程语言拿到字符的 Unicode 码点或者在 MySQL 里用CONVERT配合十六进制函数验证。验证的时候不用真的敲一个生僻字到终端MySQL 支持CHAR(码点 USING utf8mb4)这种写法。比如某个字的码点是 20000可以执行SELECT LENGTH(CHAR(20000 USING utf8mb4)), HEX(CHAR(20000 USING utf8mb4));如果LENGTH()返回 4说明这个字在 utf8mb4 下是 4 字节。这个技巧同样可以用来验证那些你不想直接打在 SQL 里的特殊符号非常实用。3. 从 UTF-8 编码规则看懂 1、2、3、4 字节是如何分配的3.1 二进制视角下的 UTF-8 分段规则UTF-8 的编码规则其实是一张表的事。码点按范围分成几段每段用不同的字节数表示每个字节的头部几位是标记位码点范围UTF-8 字节数字节格式U0000 到 U007F10xxxxxxxU0080 到 U07FF2110xxxxx 10xxxxxxU0800 到 UFFFF31110xxxx 10xxxxxx 10xxxxxxU10000 到 U10FFFF411110xxx 10xxxxxx 10xxxxxx 10xxxxxx第一字节的高位0、110、1110、11110不是冗余解析时用来判断“这是一个单字节字符还是多字节字符的开头”。后续字节统一以10开头这样即使传输过程中丢掉一段数据解码器也能很快判断当前位置是不是一个合法字符的开头。这也是 UTF-8 能成为互联网主流编码的重要原因。字母a的码点是 U0061落在第一段所以是 1 字节。汉字“汉”的码点是 U6C49落在第三段所以是 3 字节。位于 U1F600 附近的表情符号码点超过 UFFFF落在第四段所以是 4 字节。这条规则对 utf8mb3 和 utf8mb4 都成立只不过 utf8mb3 被限定为最多 3 字节一旦遇到第四段字符就无能为力。3.2 汉字和特殊符号在 Unicode 里的位置决定了最终字节数为什么日常汉字几乎都是 3 字节因为 Unicode 把常用汉字都安排在基本多文种平面码点集中在 U4E00 到 U9FFF。这个区间恰好大于 U0800、小于 UFFFF所以 UTF-8 编码必然是 3 字节。如果遇到扩展区生僻字码点在 U20000 以上那它在 utf8mb4 下就是 4 字节。这里有个容易被搞混的点MySQL 能不能存 4 字节字符看的不是字符长得复杂不复杂而是码点是否超过 UFFFF。比如某些看起来笔画很多的字只要码点在基本平面内utf8mb3 就能存反过来某些看起来简单的符号如果恰好被分配到补充平面utf8mb3 就会拒绝。字符集判断的是码点范围不是视觉复杂度。3.3 用 HEX 函数验证“3 字节”的真实编码结果在 MySQL 里可以用HEX()看字符串的实际字节内容SELECT HEX(a), HEX(汉);HEX(a)返回61正好是 1 个字节HEX(汉)返回E6B189正好是 3 个字节。如果你想验证特殊的 4 字节字符又不想在终端里输入特殊符号可以借助CHAR(码点 USING utf8mb4)SELECT LENGTH(CHAR(128512 USING utf8mb4)), HEX(CHAR(128512 USING utf8mb4));CHAR(128512 USING utf8mb4)得到的是码点 U1F600 对应的字符十六进制结果是F09F9880正好 4 个字节。这个写法可以绕开终端字符集问题因为函数指定了返回字符的字符集不受当前连接字符集的干扰。3.4 MySQL 的 utf8mb4 与标准 UTF-8 是否完全一致在绝大多数情况下可以认为 utf8mb4 就是标准 UTF-8MySQL 文档里也这么定义。但实际使用中MySQL 对某些边缘字符的处理和纯应用层 UTF-8 并不完全一样比如排序规则影响的是比较行为不是存储字节数。utf8mb4_general_ci和utf8mb4_unicode_ci在排序、大小写不敏感匹配上表现不同但同一个字符串存进数据库后占用的字节数完全一样。所以如果你在排查“为什么同样一段文本应用层算出 3 字节MySQL 也算出 3 字节但存储后查询结果却长度不对”问题大概率出在连接层字符集转换而不是 utf8mb4 本身。字符集转换发生在数据进入 MySQL 之前落库后的字节数只看列字符集和实际内容。4. 比字节数更值得关注的两个长度陷阱4.1 VARCHAR(255) 的 255 是字符数不是字节数这是字节数问题最容易连带踩坑的地方。VARCHAR(10)里的 10单位是字符不是字节。所以一个 UTF-8 编码的汉字声明成VARCHAR(10)也能存 10 个汉字实际最多占 30 字节字母a同样能存 10 个实际最多占 10 字节。很多新手拿LENGTH()去跟VARCHAR(n)做比对发现列明明写的varchar(20)LENGTH()却只有 15就会怀疑自己建错了表。实际上在 InnoDB 里一行数据的总字节数还会受 65535 字节的行大小限制。极端情况下VARCHAR(16383)在 utf8mb4 下最坏每个字符 4 字节算出来 16383*465532勉强够但还要加上 NULL 标志位和变长字段长度标记实际能声明的最大长度会比 16383 更小。这个数字看起来吓人大多数业务不会碰到但了解它的存在能避免极端设计。4.2 索引上限 767 和 3072 字节限制的是字节不是字符真正影响日常建表的是索引键值上限。InnoDB 索引键值上限按字节计算用字符集的最大字节数去乘字符数。旧配置下单列索引上限是 767 字节所以utf8mb3下VARCHAR 列最多能索引FLOOR(767/3)255个字符varchar(255)加索引刚好 765 字节不超限。utf8mb4下VARCHAR 列最多能索引FLOOR(767/4)191个字符这就是经典varchar(191)说法的来源。很多老项目表结构里出现varchar(191)并不是业务上只需要 191而是因为当年用 utf8mb4 又要加索引算出来最保险的上限。如果你的 MySQL 版本在 5.7 及以上默认行格式是 DYNAMIC且开启了innodb_large_prefix索引上限是 3072 字节utf8mb4 下可以到 768 个字符VARCHAR(255)加索引不再有问题。但如果把表改成 REDUNDANT 或 COMPACT 行格式限制又会回到 767。索引上限utf8mb3 最大字符数utf8mb4 最大字符数767 字节2551913072 字节1024768注意这里说的是“普通索引的键值上限”不是列本身能存多少。一个列存 1000 个汉字没有问题但你要给这个列加索引就得考虑前缀索引或者用哈希索引来规避。4.3 建表时怎么用最坏情况做预判建表前建议先问三个问题这个字段要不要加索引加索引的话最多需要多少字符数据里可能出现 4 字节字符吗如果字段会存比较长的标题、URL、备注又需要建立索引我通常建议把内容列保持VARCHAR(255)但用前缀索引比如KEY idx_content(content(50))或者单独拆一个短字段做索引键。不要把索引直接建在整列上尤其当业务里会出现表情符号时最坏 4 字节带来的空间浪费和索引膨胀比很多人想象中大。更稳妥的做法是在建表 SQL 里直接指定字符集CREATE TABLE article ( id INT NOT NULL AUTO_INCREMENT PRIMARY KEY, title VARCHAR(100) NOT NULL, summary VARCHAR(255), content TEXT, KEY idx_title (title) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COLLATEutf8mb4_unicode_ci;如果是在 5.7 环境里迁移varchar(255)加索引在 utf8mb4 下可能就是“Specified key was too long”的元凶。别急着把字段改短先看行格式和版本再用前缀索引或短键解决。5. 从 utf8mb3 换到 utf8mb4 的实操与踩坑记录5.1 典型报错Incorrect string value 从哪里来我帮别人排查过很多次这类问题。现象统一客户端传入一个 4 字节表情符号或其他补充平面字符落库时报Incorrect string value: \xF0\x9F\x98\x80 for column nickname at row 1F0 9F 98 80正是 4 字节 UTF-8 序列。报错说明这个列的字符集不支持 4 字节字符。此时第一件事不是急着改列而是查全链路库、表、列、连接、客户端驱动的字符集哪里还是utf8mb3或utf8哪里就会出问题。因为即使你把列改成 utf8mb4只要连接层还设置成SET NAMES utf8mb3字符在进入 MySQL 的瞬间就被当成 3 字节上限同样会出错。5.2 转换步骤和容易翻车的地方确认需要支持 4 字节字符后按下面顺序操作ALTER DATABASE your_db CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci; ALTER TABLE your_table CONVERT TO CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;第一条只改库的默认值不改变已有表第二条才是真正把表里的每一列都转成 utf8mb4。如果只想改某几列可以写成ALTER TABLE t MODIFY col VARCHAR(100) CHARACTER SET utf8mb4。转换前一定注意备份因为字符集转换会重写整个表数据量大时会锁表较长时间。如果是在线业务建议使用在线 DDL 工具或选择业务低峰期操作。还有一点容易忽略转换之后原来按 utf8mb3 设计的索引长度可能直接超限因为同样一个列在 utf8mb4 下按最大 4 字节计算索引上限能容纳的字符数会变小。遇到过不少案例执行完ALTER TABLE后下一条命令是CREATE INDEX然后报索引超长。转换前先清点哪些列上有索引估算长度是否安全。5.3 连接字符串也要同步改否则白改表改成 utf8mb4 只是存储层的事连接层如果没跟上照样报错。MySQL 客户端里可以执行SET NAMES utf8mb4;确认连接字符集。如果使用连接池连接串也要统一比如开发框架里配置characterEncodingUTF-8并且服务端把character_set_server和character_set_client都对齐到 utf8mb4。容易被忽略的是character_set_results有时客户端设置不对LENGTH()或HEX()的显示结果会骗人。排错时建议先看当前连接的全部字符集变量SHOW VARIABLES LIKE character_set%;重点看character_set_client、character_set_connection、character_set_results是否都是 utf8mb4。只有三者一致字符串字面量和查询结果才不会被中间层转出意料之外的变化。5.4 排序规则怎么选一个尽量少纠结的建议确认字符集后还要顺手决定 collation。常见的是utf8mb4_general_ci、utf8mb4_unicode_ci、utf8mb4_0900_ai_ci。这三者不影响字节数只影响比较和排序结果。如果是在老项目 5.7 上想省心就用utf8mb4_unicode_ci它对 Unicode 排序的支持更接近标准对性能非常敏感且数据基本是中英文也可以继续用utf8mb4_general_ci。8.0 默认是utf8mb4_0900_ai_ci新库直接用默认值就好。我个人在迁移旧库时不太喜欢在排序规则上做大切换因为排序规则改变可能让已有索引的排序顺序变化查询计划也可能受影响。能不换就不换除非有明确的排序需求要调整。最后再分享一个排查小技巧遇到类似字节数争议别背答案直接在生产临时库执行SELECT LENGTH()和HEX()结合SHOW CREATE TABLE看字符集。字符集是 MySQL 里少有的“一言不合就能用 SQL 实测验证”的东西比争论哪个答案更靠谱。如果你在建表时把 utf8mb4 和 utf8mb3 的区别想清楚了遇到表情符号存不进去、varchar(191)、索引超长这些问题就都能串起来了。