mysql服务端默认字符集不是utf8mb4是因历史兼容性设计，避免旧应用乱码；需同时配置character_set_server、collation_server、init_connect及skip-character-set-client-handshake四参数，并显式转换库表字符集。
MySQL服务端默认字符集为什么不是utf8mb4
MySQL 5.5.3之后就支持utf8mb4，但老版本默认还是latin1或utf8（实际是utf8mb3），后者不支持emoji和部分生僻汉字。这不是bug，是历史兼容性设计——直接改可能让旧应用乱码。
关键点：服务端字符集由character_set_server控制，它只影响新创建数据库的默认字符集，不影响已有库表；真正决定存取行为的是连接、数据库、表、列四级字符集叠加结果。
- 修改
character_set_server必须重启mysqld才生效（仅SET GLOBAL不行） - 如果只改这个值，但客户端连接时没指定
charset=utf8mb4，照样存成乱码 -
init_connect="SET NAMES utf8mb4"对SUPER权限用户无效，登录即绕过
my.cnf里必须配哪几项才算完整生效
光设character_set_server远远不够。MySQL字符集有“服务端默认”和“连接时默认”两条线，缺一不可。
在/etc/my.cnf或/usr/my.cnf的[mysqld]段下，这四行是底线配置：
[mysqld] character_set_server = utf8mb4 collation_server = utf8mb4_unicode_ci init_connect = 'SET NAMES utf8mb4' skip-character-set-client-handshake = FALSE-
collation_server必须和character_set_server匹配，否则建库时排序规则会 fallback 到latin1_swedish_ci -
init_connect能让普通用户连接时自动执行SET NAMES，但SUPER用户仍需手动SET -
skip-character-set-client-handshake设为FALSE（默认就是），才能让客户端声明的字符集被服务端尊重
ALTER database和ALTER table语句怎么写才不丢数据
已有库表不会因my.cnf修改而自动升级。必须显式转换，但顺序错一步就可能截断字段或报错。
安全做法分三步走，按顺序执行：
- 先改数据库级：
ALTER DATABASE <var>db_name</var> CHARACTER SET = utf8mb4 COLLATE = utf8mb4_unicode_ci - 再改每张表：
ALTER TABLE <var>table_name</var> CONVERT TO CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci - 最后单独确认TEXT/BLOB字段长度：
SHOW CREATE TABLE <var>table_name</var>，检查varchar(255)这类字段是否被MySQL悄悄缩成了varchar(191)（因InnoDB索引限制）
注意：CONVERT TO会重建表，大表务必在低峰期操作；如果表有外键，先删外键再转，转完再加回来。
连接时没指定utf8mb4会怎样
即使服务端全配好了，只要客户端连接字符串里没带charset=utf8mb4，MySQL就会按character_set_client解析请求——默认是latin1，导致插入emoji变成问号，读出来也是乱码。
不同场景补救方式不同：
- PHP mysqli：连接后立刻执行
$mysqli->set_charset("utf8mb4")，比在DSN里加;charset=utf8mb4更可靠 - Python PyMySQL：构造
Connection时传charset="utf8mb4"参数，不能只靠init_command - 命令行mysql：启动时加
--default-character-set=utf8mb4，否则mysql -u root -p连进去默认还是utf8
最容易被忽略的是：JDBC URL里要写useUnicode=true&characterEncoding=utf8mb4，少一个参数都不行。