故小里1. 从两个字母开始：utf8mb4_general_ci 到底管什么
我帮人排查过一个注册功能 bug，现象很典型：用户明明没重复注册，系统却提示“邮箱已被占用”。查到最后，问题出在 utf8mb4_general_ci 这个排序规则上——它把 Admin@example.com 和 admin@example.com 判定成了同一个值，唯一索引直接拦截。类似的坑我在不同项目里见过不止一次，所以这次围绕 utf8mb4_general_ci 做个完整梳理，把排序规则的作用、对比、实操和排障一次讲清楚。适合刚接触 MySQL 的开发者，也适合正在做数据库迁移、字符集统一的老手。
1.1 字符集管“存什么”，排序规则管“怎么比”
很多开发者把 utf8mb4_general_ci 当成一个整体来看，觉得它只是“支持 emoji 的字符集配置”。实际上它由两部分组成：字符集 utf8mb4 和排序规则 general_ci。字符集决定的是数据的“存储形态”，例如字符 你 在 UTF-8 编码下对应某个字节序列；排序规则决定的则是数据“比较和排序”时的行为，例如在查询 WHERE name = 'admin' 时，Admin 算不算匹配。
我习惯用一个生活类比：字符集像是“一套字典的收字范围”，规定哪些字能写进去；排序规则像是“查字典时的排序方式”，规定按笔画、按拼音、还是按字母顺序来排。同一个字，用不同的排序规则，前后顺序和是否相等都可能不一样。MySQL 的规则是先有字符集，再有基于这个字符集的一组排序规则，所以 utf8mb4_general_ci 明确告诉数据库：存储使用 UTF-8 四字节编码，比较时使用 general 这组简化规则，并忽略大小写。
1.2 utf8mb4、general、ci 分别代表什么
先从名字开始拆。utf8mb4 是一种字符集，全称是 UTF-8 MultiByte 4，每个字符最多占用 4 个字节。老项目里常见的 utf8 实际是 utf8mb3 的别名，最多只能存 3 字节，遇到生僻的 CJK 扩展字符、emoji 这类需要 4 字节编码的内容就会乱码或报错。utf8mb4 就是为了补齐这个缺口，在 MySQL 5.5.3 之后引入。
中间一段 general 表示比较规则属于“通用简化型”。它不是完全照搬 Unicode 标准中的 UCA（Unicode Collation Algorithm）排序，而是用了 MySQL 自己整理的一套简化规则，目的是让排序和比较更快。最后两个字母 ci 是 case insensitive，也就是大小写不敏感。反过来，如果看到 utf8mb4_bin，bin 代表按二进制字节值比较，也就是大小写敏感，A 和 a 会被视为不同字符。
1.3 从服务器到字段，collation 是一层层继承下来的
MySQL 的排序规则并不是只在建表语句里出现一次，它有多个层级：服务端级别、数据库级别、表级别、列级别，还有连接会话级别。当你没有显式指定某个对象的排序规则时，MySQL 会从上一级继承默认值。常见的配置方式是在 my.cnf 中这样写：
ini复制[mysqld]
character-set-server=utf8mb4
collation-server=utf8mb4_general_ci
这样新建的数据库如果没有特别指定，默认排序规则就是 utf8mb4_general_ci。新建表时如果不写在 DEFAULT CHARSET 后指定，也会继承数据库的配置。真正容易踩坑的是“列级别”：即使整张表是 utf8mb4_general_ci，某一列仍然可以单独被定义成 utf8mb4_bin 或其他排序规则。这时候普通查询可能没感觉，但多表关联或建立唯一索引时就容易出现奇奇怪怪的问题。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 等值比较、ORDER BY、JOIN：排序规则在实际 SQL 里影响什么
2.1 因为不分大小写，业务上的“唯一值”可能早已不唯一
ci 带来的最常见影响就是等值比较。实际项目里，注册系统经常用邮箱、用户名、手机号来建唯一索引，但排序规则如果是 utf8mb4_general_ci，那么 Admin@example.com 和 admin@example.com 会被视为同一个值。它真正拦截的不是同一用户重复注册，而是“只差大小写”的合法用户。
我用一个简化例子说明：
sql复制CREATE TABLE user_account (
id INT PRIMARY KEY AUTO_INCREMENT,
email VARCHAR(100) NOT NULL,
UNIQUE KEY uk_email (email)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_general_ci;
INSERT INTO user_account(email) VALUES('Admin@example.com');
INSERT INTO user_account(email) VALUES('admin@example.com');
第二条 INSERT 会直接报 Duplicate entry 'admin@example.com' for key 'uk_email'。这不是 MySQL 出错，而是排序规则带来的语义。如果业务希望“大小写不同的邮箱算两个不同用户”，就必须显式改成大小写敏感的排序规则，例如 utf8mb4_bin 或 MySQL 8.0 中的 utf8mb4_0900_as_cs。
2.2 ORDER BY 的结果，不是所有语言都按你想象的方式排
很多业务对排序的感知主要来自列表页。utf8mb4_general_ci 对普通 ASCII 字母的排序规则比较简单，大小写视为相等，所以在排序结果里 Apple 和 apple 会挨在一起。看起来没问题，但如果你想在前端做“用户名首字母分组”，或者想用 SQL 实现区分大小写的排序，这套规则就不够用了。
处理同一组数据时，不同排序规则的顺序可能发生变化。例如我建一个水果表，里面插入 Apple、apple、Banana、banana、cherry，在 utf8mb4_general_ci 下，两对大小写不同的单词会相互靠近，但它们内部的先后顺序是由 MySQL 的权重和插入顺序共同决定的。如果写 ORDER BY name COLLATE utf8mb4_bin，结果会变成大写字母全部排在小写字母前面，因为小写字母的二进制码值更大。这种差异，只有当你明确知道业务排序规则时才能有效设计。
2.3 JOIN、GROUP BY：一旦 collation 不一致，MySQL 直接报错
排序规则不一致导致的问题在单表里不太明显，多表 JOIN 时才会爆发。假设有一张 order 表的 user_email 列是 utf8mb4_general_ci，另一张 member 表的 email 列是 utf8mb4_unicode_ci，执行关联查询时很可能会见到这个经典报错：
code复制Illegal mix of collations (utf8mb4_general_ci,IMPLICIT)
and (utf8mb4_unicode_ci,IMPLICIT) for operation '='
原因是 MySQL 在比较两个字符串时，要求它们的排序规则“兼容”。如果两边都未显式声明，MySQL 会尝试按 coercibility 优先级选择，但两列都属于隐式优先级，而且排序规则不同，无法自动统一，只能抛异常。临时解决办法是在条件里加 COLLATE，例如 ON a.email = b.email COLLATE utf8mb4_general_ci，但这样可能让索引失效，最稳的做法是让两列统一到同一个排序规则。
GROUP BY 也受排序规则影响。utf8mb4_general_ci 会把只有大小写差异的字符串归为同一组，比如 SELECT email, COUNT(*) FROM user GROUP BY email，Admin@example.com 和 `admin@