大家好，我是小耶，写功课只是为了我踩过的坑，你们别再踩了！
数据库里有两个设计，平时不显山不露水，一出错就是灾难——字符集和排序规则。
你可能遇到过这些场景：从老库导数据到新库，中文变成了"锟斤拷"；两个表做JOIN，字段内容一样却关联不上；用户存了个emoji表情，数据库直接报错。
这些问题表面上看八竿子打不着，根子都在同一个地方：字符集和排序规则没搞对。
今天把字符集这件事从头到尾讲清楚，帮你避开那些让人头疼的坑。
几个先搞明白的概念
字符集（Charset）：数据库用来表示文字的编码规则。简单说，就是规定每个文字对应哪个二进制数字。不同的字符集能表示的文字范围不同——Latin1只能表示英文和西欧文字，GBK能表示中文，UTF8能表示全世界几乎所有文字。
字符编码：字符集的具体实现方式。同一个字符集可能有多种编码方式。比如UTF8字符集在MySQL里有utf8（实际是utf8mb3，最多3字节）和utf8mb4（最多4字节）两种编码，后者才能存emoji。
排序规则（Collation）：决定字符串怎么比较、怎么排序的规则。比如大小写是否敏感、中文按拼音还是按笔画排序。同一个字符集可以有不同的排序规则，排序规则选错了，JOIN和WHERE匹配就会出问题。
你可以把这三者的关系理解成：字符集决定"能写哪些字"，编码决定"每个字占几个字节"，排序规则决定"这些字怎么比大小"。
主流字符集对比
Latin1（ISO-8859-1）
最早期的单字节字符集，只能表示256个字符，覆盖英文和西欧语言。在MySQL里是早期的默认字符集。如果你的库里还有Latin1的表，存中文就会变成一堆问号——因为它压根不认识中文字。
GBK/GB2312
中文字符集。GB2312是最早的简体中文标准，包含6700多个常用汉字。GBK是它的扩展版，包含21000多个汉字和符号。如果你的系统只在国内用，GBK够用，但和国际化系统对接时，遇到繁体字或少数民族文字就会出问题。
UTF8
国际通用字符集，能表示全世界几乎所有文字。但这里有个经典大坑：MySQL里的utf8字符集其实是个"阉割版"——它最多只支持3字节编码，而真正的UTF8（RFC标准）是支持4字节的。
UTF8MB4
真正的UTF8完整实现，支持4字节编码。emoji表情、一些生僻汉字、部分特殊符号都需要4字节才能存。2018年之后，所有新项目都应该直接用utf8mb4，没有例外。
五大经典踩坑场景
场景一：数据迁移变"锟斤拷"
这是最经典的乱码场景。从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存不进去
用户输入带emoji的昵称或评论，数据库直接报错：Incorrect string value: '\xF0\x9F\x98\x80'
根因：MySQL的utf8字符集只支持3字节，emoji需要4字节。\xF0\x9F\x98\x80是一个4字节的UTF8编码序列，被utf8字符集拒绝。
解决方案：把字段、表或库的字符集改成utf8mb4：
-- 修改字段字符集
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）不同。比如一个字段用utf8mb4_general_ci，另一个用utf8mb4_unicode_ci，数据库在做比较时认为它们不是同一个规则，索引无法使用。
-- 检查两个表的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;
场景四：中文排序不对
SELECT * FROM products ORDER BY name;
按中文名称排序，结果既不是拼音顺序也不是笔画顺序，而是按二进制码点排序，完全乱序。
根因：默认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
字符集选型建议
新项目：
直接用utf8mb4，排序规则选utf8mb4_unicode_ci（国际通用）或utf8mb4_zh_pinyin_ci（中文按拼音排序）。不要犹豫，不要"先用utf8再说"。
老项目迁移：
先检查现有数据的实际编码（用HEX()函数看原始字节），确定是GBK还是UTF8。然后制定迁移计划：先改连接字符集→再改字段字符集→最后改表和库的默认字符集。不要一步到位直接ALTER全库，大数据量下会很慢。
不同场景的字符集选择：
🔹 纯国内业务，只需要中文 → GBK也可以，但不推荐（限制未来扩展）
🔹 需要存emoji、繁体字、多语言 → utf8mb4（必须）
🔹 金融、政务系统，有国密要求 → 按项目规范来，通常是utf8mb4
🔹 和老系统对接 → 先确认老系统的实际编码，再做映射
避坑检查清单
建库前过一遍这个清单，能省后续无数麻烦：
1️⃣ 数据库默认字符集 → utf8mb4
2️⃣ 建表默认字符集 → utf8mb4
3️⃣ 客户端连接字符集 → utf8mb4
4️⃣ 排序规则统一 → 同一个库内所有表用相同collation
5️⃣ 数据迁移前确认源库和目标库的字符集
6️⃣ 应用层JDBC/ORM连接字符串里指定字符集参数
能统一的地方全部统一，字符集不一致是乱码的第一大来源。
小耶在手，SQL不愁。
还有什么想了解的，欢迎留言！小耶一定知无不言言无不尽……我们下次见~
