MySQL混合utf8 utf8mb4是否比纯utf8mb4更具优势?
utf8 utf8mb4混合方式比纯utf8mb4更快速吗?是否稳定?
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
utf8 utf8mb4混合方式比纯utf8mb4更快速吗?是否稳定?
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
接受
或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
发布评论
评论(1)
没有太多优势
因为utf8mb4仅在emoji等特殊字符的时候用到了4个字节存储
其余时候表现和mysql的utf8字符集是一样的, 存储汉字仍然是3个字节
(因为mysql的utf8字符集的单个字符的最大长度方面的实现是错误的, 所以才冒出个utf8mb4字符集出来, 实际上这个utf8mb4就是标准的utf8)
当然, 需要避免使用char, 改用varchar, 因为mysql的char列类型在utf8mb4下, 为了保证所有的数据都存的下, char将会占用字符数*4的字节数 (mysql的char列类型utf8将占用字符数*3的字节数), 以保证空间分配足够. 所以建议用可变长度varchar, 以节省空间. 可变长度消耗的存储空间为: 实际存储需要的字节数+1或2个字节表达的长度.
另外对于纯英文字符的列, 你可以另外考虑varbinary(可变长度binary)和binary列(适用于固定长度的英文字符, 例如密码哈希)类型, 性能比varchar略好, 因为这个存储二进制数据
陆续被点赞, 我再补充一个 utf8 混合 utf8mb4 的坏处, 如果视图在两个分别是 utf8 和 utf8mb4 的列上使用 join, 将会导致 mysql 的性能大幅度下降(隐式类型转换), 可参考以下文章(本身也详细探讨了utf8mb4的问题):
mysql使用utf8mb4经验吐血总结
小心MySQL的隐式类型转换陷阱