MySQL 8.0 不推荐继续使用 utf8mb4_general_ci，因其已被官方标记为 deprecated，后续版本将移除；它不支持 Unicode 9.0+ 重音规则（如德语 ß≠SS 错判）、中文排序错乱，且与 utf8mb4_0900_ai_ci 混用会触发 ERROR 1267。
MySQL 8.0 默认用 utf8mb4_0900_ai_ci，新项目直接选它就行；老项目迁移或有特殊匹配需求时才需换其他规则。
为什么不能继续用 utf8mb4_general_ci
这个排序规则在 MySQL 8.0 已被标记为 deprecated，后续版本会移除。它不支持 Unicode 9.0+ 的重音处理（比如越南语、德语 ß），SELECT 'ß' = 'SS' COLLATE utf8mb4_general_ci 返回 1 是错的，实际德语中 ß 等价于 ss，但该规则没按标准实现。中文排序也常错乱，比如“张”排在“李”前面。
- 执行
SHOW COLLATION LIKE 'utf8mb4_general_ci'会看到Deprecated标记 - 跨库 JOIN 或
FIND_IN_SET混用它和utf8mb4_0900_ai_ci会直接报ERROR 1267 (HY000): Illegal mix of collations - phpMyAdmin 或 Navicat 导入旧 SQL 时若含此规则，可能卡在
Unknown collation: 'utf8mb4_general_ci'
utf8mb4_0900_ai_ci 和 utf8mb4_0900_as_cs 怎么选
核心就看两个维度：是否区分大小写（ci vs cs），是否区分重音（ai vs as）。_ai_ci 最宽松，_as_cs 最严格。
-
utf8mb4_0900_ai_ci：不区分大小写、不区分重音，适合昵称、标题、搜索字段——WHERE name LIKE '%joão%'能命中joao和João -
utf8mb4_0900_as_cs：区分大小写、区分重音，适合用户名、邮箱、API key——'User' ≠ 'user'，'café' ≠ 'cafe' - 密码字段别用任何
_ci规则，必须用utf8mb4_bin，否则'password' = 'PASSWORD'可能意外为真
改排序规则时最容易漏掉的三层
排序规则是逐层继承的：服务器 → 数据库 → 表 → 列。只改其中一层，其他层仍按旧规则走，查询行为就不可控。
MySQL8 CRM Schema Design Expert
下载
面向 CRM 系统的 MySQL 8 数据库模式设计。当用户需要为客户关系管理（CRM）系统设计、评审、优化或生成数据库模式时，应使用此项技能。
- 服务器级（影响所有新建数据库）：
[mysqld]段配character-set-server = utf8mb4+collation-server = utf8mb4_0900_ai_ci，改完必须重启 - 数据库级（影响后续新建表）：
ALTER DATABASE db_name CHARACTER SET utf8mb4 COLLATE utf8mb4_0900_ai_ci - 列级（强制生效，绕过继承）：
ALTER TABLE users MODIFY COLUMN email VARCHAR(255) COLLATE utf8mb4_0900_as_cs—— 注意必须重复声明类型，否则字段定义丢失
特别注意：CONVERT TO 会重建整张表，大表锁表时间长；而 MODIFY COLUMN 更安全，但只改单列，得一条条跑。
连接层不设 SET NAMES utf8mb4，前面全白搭
即使库、表、列全设对了，Navicat 或命令行客户端没声明字符集，MySQL 就按 character_set_client 解析输入，默认可能是 latin1，导致插入 'café' 实际存成乱码字节，后续怎么查都查不到。
- Navicat：右键连接 → “编辑连接” → “高级” → “初始命令”填
SET NAMES utf8mb4;，改完务必点“测试连接”成功再保存 - 命令行登录后手动执行一次
SET NAMES utf8mb4;，或加参数mysql --default-character-set=utf8mb4 -u user -p - 检查是否生效：
SELECT @@character_set_client, @@collation_connection;两个值都应为utf8mb4和utf8mb4_0900_ai_ci
真正容易被忽略的是：应用层连接字符串（如 JDBC URL）也得显式带 ?characterEncoding=utf8mb4，否则 ORM 写进去的还是错的。
