2023-08-15 07:37:07
在 MySQL 中存储中文字符,推荐使用 VARCHAR 类型并设置字符集为 utf8mb4,排序规则选择 utf8mb4_unicode_ci。 以下是具体说明:
字段类型选择
VARCHAR 类型:适合存储中文字符,因其可动态调整存储空间(按实际字符长度分配),避免固定长度类型(如 CHAR)的空间浪费。例如,VARCHAR(255) 可存储最多 255 个中文字符(每个字符占 3-4 字节)。
TEXT 类型:若需存储超长文本(如文章内容),可选 TEXT 类型,但需注意其无法设置默认值,且性能略低于 VARCHAR。
字符集选择
utf8mb4:必须使用此字符集,因其支持完整的 Unicode 字符集(包括中文、Emoji 及特殊符号)。
避免使用 utf8 或 latin1:
MySQL 的 utf8 仅支持最多 3 字节的字符,无法存储部分中文(如生僻字)或 Emoji。
latin1 不支持中文,会导致存储为乱码或数据丢失。
排序规则选择
utf8mb4_unicode_ci:基于 Unicode 标准排序,对中文拼音排序友好,且不区分大小写。
utf8mb4_bin:按二进制编码排序,区分大小写,但中文排序可能不符合预期。
示例:CREATE TABLE example ( id INT AUTO_INCREMENT PRIMARY KEY, name VARCHAR(255) CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci);
性能与存储空间
存储成本:utf8mb4 每个字符占用 1-4 字节(中文通常 3-4 字节),比 latin1(1 字节)或 utf8(最多 3 字节)占用更多空间。
性能影响:索引和查询可能因字符集变大而稍慢,但现代硬件下影响通常可接受。优化建议:
合理设置字段长度(如 VARCHAR(100) 而非 VARCHAR(255))。
对常用查询字段添加索引。
常见问题与解决方案
乱码或数据丢失:
原因:表/字段字符集未设为 utf8mb4,或连接数据库时未指定字符集。
解决:
创建表时显式指定字符集:CREATE TABLE example (...) CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;
连接数据库时添加参数:jdbc:mysql://localhost:3306/db?characterEncoding=utf8mb4&useUnicode=true
已有表修复:ALTER TABLE example CONVERT TO CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;
经验总结
始终使用 utf8mb4:避免因字符集不支持导致的乱码或数据丢失。
统一字符集设置:确保表、字段、连接及客户端字符集一致(均为 utf8mb4)。
测试验证:插入含中文和 Emoji 的数据,验证存储和查询是否正常。
通过以上配置,可安全高效地存储中文字符,并避免常见问题。