应选择utf8mb4字符集和utf8mb4_unicode_ci排序规则，以支持完整Unicode并确保多语言正确排序，避免乱码与性能问题。

在mysql数据库中，字符集（Character Set）和排序规则（Collation）的选择直接影响数据的存储、比较和排序行为。选错可能导致乱码、查询异常或性能问题。以下是关键选择建议。

理解字符集的作用

字符集决定了数据库能存储哪些字符：

• utf8mb4 是目前最推荐的字符集，支持完整的Unicode，包括表情符号（如 ?、?）和生僻汉字
• 老版本的 utf8 实际只支持最多3字节，无法正确存储4字节字符（如部分emoji），应避免使用
• 如果仅存储英文和数字，latin1 节省空间，但扩展性差

排序规则如何影响数据比较

排序规则定义了字符的比较和排序方式，通常依附于字符集：

序列猴子开放平台

具有长序列、多模态、单模型、大数据等特点的超大规模语言模型

0

查看详情

• utf8mb4_unicode_ci：基于Unicode标准排序，支持多语言，推荐用于国际化应用
• utf8mb4_general_ci：旧版通用排序，速度快但准确性略低，不推荐新项目使用
• utf8mb4_bin：区分大小写和重音，按二进制比较，适合需要精确匹配的场景
• _ci 表示大小写不敏感（case-insensitive），_cs 或 _bin 区分大小写

实际配置建议

为避免混乱，应在多个层级统一设置：

• 创建数据库时指定：CREATE database mydb CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;
• 建表时继承或显式声明字符集和排序规则
• 连接层也要保持一致，在连接字符串中加入 charset=utf8mb4
• 检查当前设置可用：SHOW VARIABLES LIKE ‘character_set%’; 和 SHOW VARIABLES LIKE ‘collation%’;

常见问题规避

生产环境中容易忽略的细节：

• 不同排序规则的列之间做JOIN可能引发性能下降或结果异常
• ALTER table 修改字符集时注意索引长度限制，尤其是变长字符（如utf8mb4下VARCHAR(255)可能超过索引限制）
• 从utf8升级到utf8mb4需评估存储增长（最多增加33%）

基本上就这些。坚持使用 utf8mb4 + utf8mb4_unicode_ci 可覆盖绝大多数场景，兼顾兼容性和准确性。不复杂但容易忽略的是保持各层（服务器、数据库、表、连接）的一致性。