mysql 修改字符集为utf8mb4
一般情况下，我们会设置MySQL默认的字符编码为utf8，但是近些年来，emoji表情的火爆使用，给数据库带来了意外的错误，就是emoji的字符集已经超出了utf8的编码范畴。
utf-8编码可能2个字节、3个字节、4个字节的字符，但是MySQL的utf8编码只支持3字节的数据，而表情数据是4个字节的字符。如果直接往采用utf-8编码的数据库中插入表情数据，Java程序中将报SQL异常：
java.sql.SQLException: Incorrect string value: |xF0x9Fx92x94| for column |name| at row 1
at com.mysql.jdbc.SQLError.createSQLException(SQLError.java:1073)
at com.mysql.jdbc.MysqlIO.checkErrorPacket(MysqlIO.java:3593)
at com.mysql.jdbc.MysqlIO.checkErrorPacket(MysqlIO.java:3525)
at com.mysql.jdbc.MysqlIO.sendCommand(MysqlIO.java:1986)
at com.mysql.jdbc.MysqlIO.sqlQueryDirect(MysqlIO.java:2140)
at com.mysql.jdbc.ConnectionImpl.execSQL(ConnectionImpl.java:2620)
at com.mysql.jdbc.StatementImpl.executeUpdate(StatementImpl.java:1662)
at com.mysql.jdbc.StatementImpl.executeUpdate(StatementImpl.java:1581)
可以对4字节的字符进行编码存储，然后取出来的时候，再进行解码。但是这样做会使得任何使用该字符的地方都要进行编码与解码。
+++
令人抓狂的字符编码问题
谈到字符编码问题，会让很多人感到头疼，这里不在深究各个字符编码的特点和理论，这里只说下Unicode和utf8字符编码的关系
Unicode是编码字符集，而UTF-8就是字符编码，即Unicode规则字库的一种实现形式。
随着互联网的发展，对同一字库集的要求越来越迫切，Unicode标准也就自然而然的出现。
它几乎涵盖了各个国家语言可能出现的符号和文字，并将为他们编号。
详见：Unicode on Wikipedia。
Unicode的编号从0000开始一直到10FFFF共分为16个Plane，每个Plane中有65536个字符。
而UTF-8则只实现了第一个Plane，可见UTF-8虽然是一个当今接受度最广的字符集编码，但是它并没有涵盖整个Unicode的字库，这也造成了它在某些场景下对于特殊字符的处理困难。
简单的说在计算机内存中，统一使用Unicode编码，当需要保存到硬盘或者需要传输的时候，就转换为UTF-8编码。
用记事本编辑的时候，从文件读取的UTF-8字符被转换为Unicode字符到内存里，编辑完成后，保存的时候再把Unicode转换为UTF-8保存到文件
+++
什么是utf8mb4
emoji是Unicode编码，在MySQL中使用utf8编码无法正常显示emoji的表情，为了解决这个问题，MySQL在5.5.3版本之后，引进了新的字符编码utf8mb4,本篇文章主要介绍如何将已经是utf8的database切换到utf8mb4字符编码
utf8mb4最明显的好处是解决了苹果挖的坑-推广了emoji表情。utf8mb4解决了MySQL数据库存储emoji表情的问题
utf8mb4编码是utf8编码的超集，理论上由utf8升级到utf8mb4字符编码没有任何兼容问题，兼容utf8，并且能存储4字节的表情字符。
采用utf8mb4编码的好处是：存储与获取数据的时候，不用再考虑表情字符的编码与解码问题。
emoji是Unicode编码，在MySQL中使用utf8编码无法正常显示emoji的表情，为了解决这个问题，MySQL在5.5.3版本之后，引进了新的字符编码utf8mb4,本篇文章主要介绍如何将已经是utf8的database切换到utf8mb4字符编码
+++
升级utf8到utf8mb4
1. 备份
安全第一，备份所有需要升级字符编码的数据库
可以将库dump出来
如果是虚拟机，可以给整个主机做快照
2. 升级
utf8mb4是MySQL5.5.3版本之后支持的字符集，so，如果你需要使用这个字符集，前提条件是你的MySQL版本必须 >= 5.5.3
3. 修改
在MySQL中，可以为一个database设置字符编码，可以为一张表设置字符编码，甚至可以为某一个字段设置字符编码
--查看当前系统默认的字符集设置
SHOW VARIABLES WHERE Variable_name LIKE |character\_set\_%| OR Variable_name LIKE |collation%|;
--查看database的字符编码
show create database gugehome;
--查看table的字符编码
show create table gugehome;
--查看column的字符编码
show full columns from gugehome;
开始修改
--修改database默认的字符集
ALTER DATABASE database_name CHARACTER SET = utf8mb4 COLLATE = utf8mb4_unicode_ci
--虽然修改了database的字符集为utf8mb4，但是实际只是修改了database新创建的表，默认使用utf8mb4，原来已经存在的表，字符集并没有跟着改变，需要手动为每张表设置字符集
--修改table的字符集
--只修改表默认的字符集
ALTER TABLE table_name DEFAULT CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;
--修改表默认的字符集和所有字符列的字符集
ALTER TABLE table_name CONVERT TO CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;
--单独修改column默认的字符集
ALTER TABLE table_name CHANGE column_name column_name VARCHAR(300) CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;
--注：VARCHAR(300) 根据字段实例的类型填写
4. 检查字段的最大长度和索引列
--字段长度
由于从utf8升级到了utf8mb4，一个字符所占用的空间也由3个字节增长到4个字节，但是我们当初创建表时，设置的字段类型以及最大的长度没有改变。例如，你在utf8下设置某一字段的类型为TINYTEXT, 这中字段类型最大可以容纳255字节，三个字节一个字符的情况下可以容纳85个字符，四个字节一个字符的情况下只能容纳63个字符，如果原表中的这个字段的值有一个或多个超过了63个字符，那么转换成utf8mb4字符编码时将转换失败，你必须先将TINYTEXT更改为TEXT等更高容量的类型之后才能继续转换字符编码
--索引
在InnoDB引擎中，最大的索引长度为767字节，三个字节一个字符的情况下，索引列的字符长度最大可以达到255，四个字节一个字符的情况下，索引的字符长度最大只能到191。如果你已经存在的表中的索引列的类型为VARCHAR(255)那么转换utf8mb4时同样会转换失败。你需要先将VARCHAR(255)更改为VARCHAR(191)才能继续转换字符编码
5. 修改配置文件
SET NAMES utf8 COLLATE utf8_unicode_ci becomes SET NAMES utf8mb4 COLLATE utf8mb4_unicode_ci
> vim /etc/my.cnf
# 对本地的mysql客户端的配置
[client]
default-character-set = utf8mb4
# 对其他远程连接的mysql客户端的配置
[mysql]
default-character-set = utf8mb4
# 本地mysql服务的配置
[mysqld]
character-set-client-handshake = FALSE
character-set-server = utf8mb4
collation-server = utf8mb4_unicode_ci
init_connect=|SET NAMES utf8mb4|
--保存退出，重启服务
> service mysqld restart
检查修改
mysql> SHOW VARIABLES WHERE Variable_name LIKE |character\_set\_%| OR Variable_name LIKE |collation%|;
+--------------------------+--------------------+
| Variable_name | Value |
+--------------------------+--------------------+
| character_set_client | utf8mb4 |
| character_set_connection | utf8mb4 |
| character_set_database | utf8mb4 |
| character_set_filesystem | binary |
| character_set_results | utf8mb4 |
| character_set_server | utf8mb4 |
| character_set_system | utf8 |
| collation_connection | utf8mb4_unicode_ci |
| collation_database | utf8mb4_unicode_ci |
| collation_server | utf8mb4_unicode_ci |
+--------------------------+--------------------+
10 rows in set (0.01 sec)
注：
1）character_set_system 一直都会是 utf8，不能被更改
2）collation_connection 、collation_database 、collation_server是什么没关系。
但必须保证以下变量必须是utf8mb4。
character_set_client (客户端来源数据使用的字符集)
character_set_connection (连接层字符集)
character_set_database (当前选中数据库的默认字符集)
character_set_results (查询结果字符集)
character_set_server (默认的内部操作字符集)
6. 修复&优化所有数据表
> mysqlcheck -u root -p --auto-repair --optimize --all-databases
7. 数据库连接的配置(可能不必设置）
数据库连接参数中:
characterEncoding=utf8会被自动识别为utf8mb4，也可以不加这个参数，会自动检测。
而autoReconnect=true是必须加上的。
8. 创建新表时要指定为utf8mb4
CREATE TABLE |table| (
|id| int NOT NULL auto_increment,
|name| varchar(50) NOT NULL,
primary key(|id|)
) ENGINE=InnoDB CHARSET=utf8mb4 AUTO_INCREMENT=1;
总结
不要在MySQL上使用utf8字符编码，推荐使用utf8mb4，至于为什么，引用国外友人的一段话：
Never use utf8 in MySQL — always use utf8mb4 instead. Updating your databases and code might take some time, but it’s definitely worth the effort. Why would you arbitrarily limit the set of symbols that can be used in your database? Why would you lose data every time a user enters an astral symbol as part of a comment or message or whatever it is you store in your database? There’s no reason not to strive for full Unicode support everywhere. Do the right thing, and use utf8mb4.
永远不要在MySQL中使用utf8-始终使用utf8mb4。更新您的数据库和代码可能需要一些时间，但这绝对是值得的。为什么要任意限制数据库中可以使用的符号集？为什么每次用户输入一个星体符号作为评论或消息的一部分或者存储在数据库中的任何内容，都会丢失数据？没有理由不争取在任何地方都完全支持Unicode。做正确的事情，并使用utf8mb4。
Tag: 字符集 utf8 utf8mb4 表情符
