乱码主因是客户端、连接层、表字段三者字符集未统一为utf8mb4;必须通过SHOW VARIABLES LIKE 'character_set%'确认character_set_client、connection、results全为utf8mb4,建表改表须用CONVERT TO,应用连接必须显式指定charset=utf8mb4。

乱码不是数据库“坏了”,而是字符集在客户端、连接层、表字段三者之间没对齐。只改其中一环,基本白忙。
查当前实际生效的字符集配置
别信配置文件或建库语句里的默认值,运行时可能被覆盖。连上 MySQL 后立刻执行:
SHOW VARIABLES LIKE 'character_set%';
重点关注这三项是否全为 utf8mb4:
character_set_clientcharacter_set_connectioncharacter_set_results
只要有一个是 latin1 或 utf8(注意:不是 utf8mb4),插入中文就大概率变问号或乱码。另外 character_set_server 和 character_set_database 是服务端默认值,只影响新对象,不修复已有字段。
改表字段字符集必须用 CONVERT TO,不能只改表级声明
ALTER TABLE table_name CHARACTER SET utf8mb4 这类语句只改表元数据,字段实际存储仍按旧字符集编码,无效。
真正生效的是:
ALTER TABLE your_table_name CONVERT TO CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;
但要注意:
- 大表执行会锁表、重建索引、临时磁盘空间翻倍,线上务必选低峰期
- 如果字段有全文索引,
utf8mb4下单列索引长度上限是 767 字节(InnoDB 默认),需配合innodb_large_prefix=ON和ROW_FORMAT=DYNAMIC - 若只想改某列(比如 TEXT 类型),用
MODIFY更可控:ALTER TABLE t MODIFY content TEXT CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;,但必须重写完整字段定义,否则可能丢 NOT NULL 或 DEFAULT 约束
连接层不设 charset=utf8mb4,前面全白搭
即使数据库、表、字段全设成 utf8mb4,只要应用连接没声明字符集,MySQL 仍按 latin1 解析请求——这是最常被忽略的一环。
不同场景写法不同:
- PHP PDO:
mysql:host=localhost;charset=utf8mb4必须写进 DSN - Java JDBC:
jdbc:mysql://localhost:3306/db?useUnicode=true&characterEncoding=utf8mb4,注意 URL 中&要转义,且驱动版本建议 8.0+ - 命令行 mysql 客户端:
mysql --default-character-set=utf8mb4 -u root -p,否则默认用latin1 - Navicat:右键连接 →「编辑连接」→「高级」→ 勾选「使用 MySQL 字符集」并选
utf8mb4
漏掉任何一处,character_set_client 就不会变成 utf8mb4,后续所有环节都跟着错。
SQL Server 视图中文乱码要盯住列级排序规则
SQL Server 不叫“字符集”,但原理类似:乱码常因列级 collation 和数据库默认不一致。
先查当前库排序规则:
SELECT name, collation_name FROM sys.databases WHERE name = 'your_db';
如果是 SQL_Latin1_General_CP1_CI_AS,建表时没显式指定,字段就继承这个,但中文查询仍可能乱码。
解决方式是显式修正列:
- 新建列时写死:
name NVARCHAR(50) COLLATE Chinese_PRC_CI_AS - 已有列用:
ALTER TABLE t ALTER COLUMN name NVARCHAR(50) COLLATE Chinese_PRC_CI_AS
ALTER DATABASE ... COLLATE 只影响新对象,老字段完全不受力——这点和 MySQL 的 ALTER DATABASE 类似,容易误判。
真正卡住人的,从来不是“该不该用 utf8mb4”,而是三处字符集(client/connection/results)有没有在连接建立那一刻就对齐;还有 SQL Server 里,字段是不是真用了中文排序规则,而不是只看数据库层面的设置。

















