应选择utf8mb4字符集和utf8mb4_unicode_ci排序规则，以支持完整Unicode并确保多语言正确排序，避免乱码与性能问题。
在MySQL数据库中，字符集（Character Set）和排序规则（Collation）的选择直接影响数据的存储、比较和排序行为。选错可能导致乱码、查询异常或性能问题。以下是关键选择建议。
理解字符集的作用
字符集决定了数据库能存储哪些字符：
- utf8mb4 是目前最推荐的字符集，支持完整的Unicode，包括表情符号（如 ?、?）和生僻汉字
- 老版本的 utf8 实际只支持最多3字节，无法正确存储4字节字符（如部分emoji），应避免使用
- 如果仅存储英文和数字，latin1 节省空间，但扩展性差
排序规则如何影响数据比较
排序规则定义了字符的比较和排序方式，通常依附于字符集：
- 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 可覆盖绝大多数场景，兼顾兼容性和准确性。不复杂但容易忽略的是保持各层（服务器、数据库、表、连接）的一致性。
