utf8mb4和utf8有什么区别？

在 MySQL 数据库中，utf8和utf8mb4是两种常见的字符集，两者的核心区别在于对 Unicode 字符的支持范围，尤其体现在对 4 字节字符的处理上。以下是具体对比和解析：

一、核心区别：对 4 字节字符的支持

• utf8：

   

  是 MySQL 早期实现的 UTF-8 字符集，但存在局限性 ——仅支持最多 3 字节的 Unicode 字符。

   

  它能覆盖大部分常见文字（如中文、英文、日文等属于 “基本多语言平面” 的字符，编码范围U+0000至U+FFFF），但无法存储 4 字节的 Unicode 字符（编码范围U+10000至U+10FFFF），例如：
  • Emoji 表情（如😊、🥇，编码U+1F60A、U+1F947）；
  • 某些罕见语言文字（如古埃及象形文字、数学符号𝌆等）。
• utf8mb4：

   

  是 MySQL5.5.3 版本后推出的 “完整 UTF-8” 字符集，其中 “mb4” 即 “most bytes 4”，表示支持最多 4 字节的 Unicode 字符。

   

  它完全兼容所有 Unicode 标准字符，包括上述utf8无法处理的 4 字节字符，是真正意义上的 UTF-8 实现。

二、其他关键差异

对比维度	utf8	utf8mb4
字符覆盖范围	仅支持 3 字节以内的 Unicode 字符	支持所有 Unicode 字符（1-4 字节）
存储开销	每个字符占 1-3 字节	每个字符占 1-4 字节（平均开销略高）
兼容性	不支持 Emoji 和 4 字节特殊字符	完全支持 Emoji 和所有特殊字符
MySQL 默认字符集	MySQL8.0 前部分版本默认	MySQL8.0 及以上默认字符集
索引长度限制	相同长度字段的索引字节数更少（如 VARCHAR (255) 最多占 765 字节）	相同长度字段的索引字节数更多（如 VARCHAR (255) 最多占 1020 字节，可能触发索引长度限制）

三、使用场景建议

1. 优先选择utf8mb4的场景：
   • 需要存储 Emoji 表情（如社交软件、用户昵称、评论系统）；
   • 涉及多语言场景，尤其是可能包含罕见文字或特殊符号（如学术研究、跨国应用）；
   • 新系统开发（MySQL8.0 已默认使用utf8mb4，无需额外配置即可兼容所有字符）。
2. 可保留utf8的场景：
   • 旧系统迁移，且明确无需支持 4 字节字符（如纯英文系统、内部管理系统，且无扩展需求）；
   • 对存储开销和索引性能有极致要求，且能确保不会出现 4 字节字符（需谨慎评估，避免未来扩展受限）。

四、常见问题与注意事项

• 插入失败报错：若用utf8字符集插入 4 字节字符（如 Emoji），会提示Incorrect string value错误，此时需将字符集改为utf8mb4。
• 索引长度问题：utf8mb4的 4 字节特性可能导致长字符串字段（如VARCHAR(255)）创建索引时超出 InnoDB 的默认长度限制（767 字节），需通过启用innodb_large_prefix或创建前缀索引解决。
• 兼容性影响：utf8mb4是utf8的超集，从utf8迁移到utf8mb4不会导致数据丢失，只需修改字符集配置即可平滑过渡。

总结

utf8mb4是utf8的完善版本，解决了对 4 字节 Unicode 字符的支持问题，是现代应用的推荐选择。而utf8因局限性，仅适合明确无需处理 Emoji 或特殊符号的场景。在实际开发中，除非有特殊原因，否则应优先使用utf8mb4以确保字符兼容性。