大家好，我是小耶，写功课只是为了我踩过的坑，你们别再踩了！

数据库里有两个设计，平时不显山不露水，一出错就是灾难——字符集和排序规则。

你可能遇到过这些场景：从老库导数据到新库，中文变成了"锟斤拷"；两个表做JOIN，字段内容一样却关联不上；用户存了个emoji表情，数据库直接报错。

这些问题表面上看八竿子打不着，根子都在同一个地方：字符集和排序规则没搞对。

今天把字符集这件事从头到尾讲清楚，帮你避开那些让人头疼的坑。

：数据库用来表示文字的编码规则。简单说，就是规定每个文字对应哪个二进制数字。不同的字符集能表示的文字范围不同——Latin1只能表示英文和西欧文字，GBK能表示中文，UTF8能表示全世界几乎所有文字。

：字符集的具体实现方式。同一个字符集可能有多种编码方式。比如UTF8字符集在MySQL里有utf8（实际是utf8mb3，最多3字节）和utf8mb4（最多4字节）两种编码，后者才能存emoji。

：决定字符串怎么比较、怎么排序的规则。比如大小写是否敏感、中文按拼音还是按笔画排序。同一个字符集可以有不同的排序规则，排序规则选错了，JOIN和WHERE匹配就会出问题。

你可以把这三者的关系理解成：字符集决定"能写哪些字"，编码决定"每个字占几个字节"，排序规则决定"这些字怎么比大小"。

最早期的单字节字符集，只能表示256个字符，覆盖英文和西欧语言。在MySQL里是早期的默认字符集。如果你的库里还有Latin1的表，存中文就会变成一堆问号——因为它压根不认识中文字。

中文字符集。GB2312是最早的简体中文标准，包含6700多个常用汉字。GBK是它的扩展版，包含21000多个汉字和符号。如果你的系统只在国内用，GBK够用，但和国际化系统对接时，遇到繁体字或少数民族文字就会出问题。

国际通用字符集，能表示全世界几乎所有文字。但这里有个经典大坑：MySQL里的

字符集其实是个"阉割版"——它最多只支持3字节编码，而真正的UTF8（RFC标准）是支持4字节的。

真正的UTF8完整实现，支持4字节编码。emoji表情、一些生僻汉字、部分特殊符号都需要4字节才能存。2018年之后，

这是最经典的乱码场景。从GBK编码的旧库导出数据，导入到UTF8编码的新库，中文全变成了乱码。

根因：导出时数据库按GBK编码把中文转成二进制，导入时新库按UTF8去解码，同样的二进制串在两种编码下对应的文字完全不同，就出现了乱码。

-- 查看当前库的字符集设置
SHOW VARIABLES LIKE 'character_set%';

-- 查看某张表的字符集
SHOW CREATE TABLE table_name;

-- 查看某个字段的字符集
SELECT COLUMN_NAME, CHARACTER_SET_NAME, COLLATION_NAME
FROM information_schema.COLUMNS
WHERE TABLE_SCHEMA = 'your_db' AND TABLE_NAME = 'your_table';


# 导出时指定字符集
mysqldump --default-character-set=gbk old_db > dump.sql

# 导入时指定目标字符集
mysql --default-character-set=utf8mb4 new_db < dump.sql


用户输入带emoji的昵称或评论，数据库直接报错：

Incorrect string value: '\xF0\x9F\x98\x80'

字符集只支持3字节，emoji需要4字节。

是一个4字节的UTF8编码序列，被

：把字段、表或库的字符集改成

-- 修改字段字符集
ALTER TABLE users MODIFY nickname VARCHAR(50)
CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;

-- 修改整张表字符集
ALTER TABLE users CONVERT TO CHARACTER SET utf8mb4;


场景三：JOIN因为collation不同走不了索引

两个表做JOIN，关联字段内容完全一样，但结果不对或者走了全表扫描。

根因：两个字段的排序规则（collation）不同。比如一个字段用

，数据库在做比较时认为它们不是同一个规则，索引无法使用。

-- 检查两个表的collation是否一致
SHOW CREATE TABLE table_a;
SHOW CREATE TABLE table_b;


：统一collation。建议在同一个数据库中，所有表使用相同的字符集和排序规则：

-- 统一修改字段collation
ALTER TABLE orders MODIFY user_id VARCHAR(50)
COLLATE utf8mb4_unicode_ci;


按中文名称排序，结果既不是拼音顺序也不是笔画顺序，而是按二进制码点排序，完全乱序。

根因：默认collation是二进制比较，不是按拼音排序。

：使用支持中文排序的collation：

-- MySQL 8.0+，使用utf8mb4_zh_pinyin_ci
SELECT * FROM products ORDER BY name COLLATE utf8mb4_zh_pinyin_ci;

-- 或者建表时指定
CREATE TABLE products (
    name VARCHAR(100) COLLATE utf8mb4_zh_pinyin_ci
);


场景五：连接层字符集不对导致乱码

数据库和表都设了utf8mb4，但客户端插入中文还是乱码。

根因：客户端连接的字符集设置和数据库不一致。客户端按自己的字符集发送数据，数据库按连接字符集做转换，如果连接字符集设错了，数据在入库前就已经被错误转换。

-- 连接后立即执行
SET NAMES utf8mb4;

-- 或者在连接字符串/配置文件中指定
-- MySQL: ?characterEncoding=utf8mb4
-- JDBC: jdbc:mysql://host/db?characterEncoding=utf8mb4&useUnicode=true


（中文按拼音排序）。不要犹豫，不要"先用utf8再说"。

先检查现有数据的实际编码（用

函数看原始字节），确定是GBK还是UTF8。然后制定迁移计划：先改连接字符集→再改字段字符集→最后改表和库的默认字符集。不要一步到位直接ALTER全库，大数据量下会很慢。

🔹 纯国内业务，只需要中文 → GBK也可以，但不推荐（限制未来扩展）

🔹 需要存emoji、繁体字、多语言 → utf8mb4（必须）

🔹 金融、政务系统，有国密要求 → 按项目规范来，通常是utf8mb4

🔹 和老系统对接 → 先确认老系统的实际编码，再做映射

建库前过一遍这个清单，能省后续无数麻烦：

1️⃣ 数据库默认字符集 → utf8mb4

2️⃣ 建表默认字符集 → utf8mb4

3️⃣ 客户端连接字符集 → utf8mb4

4️⃣ 排序规则统一 → 同一个库内所有表用相同collation

5️⃣ 数据迁移前确认源库和目标库的字符集

6️⃣ 应用层JDBC/ORM连接字符串里指定字符集参数

能统一的地方全部统一，字符集不一致是乱码的第一大来源。

还有什么想了解的，欢迎留言！小耶一定知无不言言无不尽……我们下次见~

字符集没统一，DBA的头发就是这么掉光的

本文讲解数据库字符集（UTF8/GBK/Latin1）和排序规则（collation）的底层原理，分析数据迁移乱码、JOIN因collation不同走不了索引、emoji存储失败等常见问题的根因，给出字符集选型建议和排查方法。

数据库

运维

数据迁移

大数据

国密

MySQL

腾讯云数据库特惠，新用户首单0.5折起


文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

EdgeOne AI 安全实战专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

字符集没统一，DBA的头发就是这么掉光的

字符集没统一，DBA的头发就是这么掉光的

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐