论不要在mysql中使用[utf8]编码，如果要用请用[utf8mb4]
管理员 发布于 3年前 728
mysql中请放弃utf8使用utf8mb4编码
MySQL 的 utf8 不是 UTF-8
「utf8」编码只支持每个字符占三个字节。真正的 UTF-8 编码是 - 每个人都使用，包括你自己 - 每个字符需要四个字节。
MySQL 的开发人员并没有修复这个 bug，但是他们在 2010 年发布了一个解决方案：一种叫做「utf8mb4」的新编码。
当然，他们并没有对外宣传这件事 (大概是因为这个 bug 太尴尬了)，现在网上仍然有很多教程让我们使用「utf8」编码，但都是错的。
简而言之：
MySQL 的「utf8mb4」才是真正意义上的「UTF-8」。
MySQL 的「utf8」指的是「一种专有的编码」，这种编码有很多 Unicode 字符不能编码。
我在此做一个明确的声明：所有还在使用「utf8」编码的 MySQL 和 MariaDB 的用户实际上应当使用「utf8mb4」编码。而不应该继续使用「utf8」。
MySQL中 [utf8] / UTF-8 的历史故事
为什么 MySQL 的开发者使用这种不合理的「utf8」？我们可以通过 MySQL 的 commit 日志猜测一下。
MySQL 从 version 4.1 开始支持 UTF-8，大约是在 2003 的时候，比现在的 UTF-8 标准，RFC 3629 还要早。
而以前使用的是 RFC 2279 这套 UTF-8 标准，这套标准中每个字符 6 个字节。MySQL 开发者在 first pre-pre-release version of MySQL 4.1，也就是 2002 年 3 月 28 号实现 RFC 2279 标准。
然后又发生了一件神奇的事情，MySQL 的源代码在 9 月的版本中有一个字节的调整：「UTF8 最大仅支持 3 个字节序列」。
是谁发起了这个 commit？为什么发布这个 commit？我并不知晓。MySQL 的代码仓库似乎在采用 Git 作为版本控制后丢失了一些曾经的贡献者的名字（MySQL 过去的使用的是 BitKeeper 版本控制，像 Linux 内核一样）。MySQL 官方也没有在 2003 年 9 月的正式版发布时的邮件清单中解释这个变更。
但是我可以猜想。
我们说回 2002 年，MySQL 告诉用户，如果用户需要保证每条记录在表中有相同的字节长度的话，有一套 加速优化方案 可以使用。这套方案要求用户在定义字符字段的时候使用「CHAR」类型。一个「CHAR」类型的字段不管存储的数据内容是什么，存储的字符数量始终相同。如果存储的字符比字段规定的要少，会使用空格在结尾填充，直到数量匹配为止；如果存储的字符比字段规定的要多时，会截断多出来的字符。
当 MySQL 开发人员第一次尝试 UTF-8 时，就是还在使用每个字符 6 个字节这种方案时，他们似乎有些犹豫：一个 CHAR(1) 的列会使用 6 个字节长度；一个 CHAR(2) 的列会使用 12 个字节长度等等。
明确的说：他们最初的没有正式发布的做法是正确的，这种解决方案是有据可查且广泛适用的，任何一个只要是理解 UTF-8 编码的人都会认同这个方案。
但是很明显，MySQL 开发人员（或者是发行商）考虑到可能有一些用户会做这两件事情：
1.使用 CHAR 类型字段。（CHAR 字段现在基本没人使用了。但是在当时，MySQL 中使用 CHAR 字段会有更优的速度，但是在 2005 年之后却并非如此）
2.将 CHAR 字段列的编码设置为「utf8」。
我的猜测是 MySQL 开发人员为了方便那些既想优化空间和时间性能，又没能成功优化空间和时间性能的用户，废弃了原有的「utf8」编码。
然而没有人能得到自己想要的。想要优化时间和空间性能的用户仍旧在错误的使用「utf8」CHAR 字段，但是这些字段往往会很大，导致 MySQL 的速度比不使用 CHAR 的时候还要慢。而那些想要使用真正的 UTF-8 的用户错误的使用了「utf8」，导致他们不能存储「?」这类字符。
但是，一旦 MySQL 发布这个无用的字符编码，就再也不能修复它了：
因为这会令所有的用户都要重新构建每一个数据库。所以 MySQL 最终在 2010 年发布了真正的 UTF-8，不过使用了另一个名字「utf8mb4」。
总结
1.数据库系统有微妙的错误和异常，你可以通过数据库的选择避免许多错误。
2.如果你需要一个数据库， 不要使用 MySQL 或者 MariaDB。 使用 PostgreSQL。
3.如果你需要使用 MySQL 或 MariaDB，千万不要使用「UTF8」。当你想要 UTF-8 时，总是使用「UTF8Mb4」。现在去 转换你的数据库吧避免发生头痛的事。
转：https://medium.com/@adamhooper/in-mysql-never-use-utf8-use-utf8mb4-11761243e434
请勿发布不友善或者负能量的内容。与人为善，比聪明更重要！
该博客于2020-12-7日，后端基于go语言的beego框架开发
前端页面使用Bootstrap可视化布局系统自动生成
是我仿的原来我的TP5框架写的博客，比较粗糙，底下是入口
侯体宗的博客
文章标签
- test 三种扣减库存方案 Hyperf2.1启动报错端口占用 上外网神器Ghelper 上外网神器集装箱 laravel中HMVC模式 Hyperf框架验证器 Hyperf自定义函数编写 Hyperf对象转成数组 PHP2021面试题集 centos7系统上挂载 Hyperf框架 秒杀系统的设计 Laravel Octane PHP数组底层实现原理 php7垃圾回收机制 Laravel中类型转换 mysql事务特征及隔离级别 Linux-awk命令 mysql编码 JWT源码实现 Laravel内核分析 Laravel中的用法 centos7+go环境+beego框架 go+beego框架开发博客 go+beego开发博客首页 go+beego自定义公共函数 beego注册_登录_查询 beego控制器创建 Beego框架安装 go语言环境安装 laravel+Elasticsearc laravel运行原理 windows7搭建Vuejs环境 Laravel分块 laravel去重(distinct() laravel集合 laravel+mysql读写分离 laravel5+复杂原生sql laravel+MissMyCat/al lnmp sessio laravel自定义数组分页 laravel中.env配置 laravel8队列发邮件 码云仓库常用操作 laravel8配置163SMTP laravel8配置全局函数 laravel/jetstream之认证 laravel/jetstream
友情链接
