utf8mb4是mysql 5.5.3+中唯一支持完整utf-8（含emoji及生僻汉字）的字符集，utf8实为utf8mb3，强行降级会导致数据截断、乱码或插入失败；性能优化必须建立在utf8mb4基础上，通过合理设置buffer pool、索引长度、排序规则及字段类型来实现。
为什么 utf8mb4 是唯一合理选择
MySQL 5.5.3+ 的 InnoDB 中，utf8 实际是 utf8mb3（最多 3 字节），不支持 emoji 和部分生僻汉字；真正完整的 UTF-8 是 utf8mb4。强行用 latin1 或 utf8 虽然字段存储更省空间，但会直接导致数据截断、乱码或插入失败——这不是“性能优化”，是数据事故。
所谓“平衡性能与空间”，前提是数据正确。所有性能讨论都建立在 utf8mb4 基础上，而非拿掉它去换虚假的效率。
字符集对 InnoDB 性能的真实影响点
utf8mb4 确实比 latin1 占更多内存和索引空间，但关键影响集中在三处：
-
innodb_buffer_pool_size：相同文本在utf8mb4下可能多占 2–4 倍内存（如 emoji 占 4 字节），缓冲池命中率可能下降 → 需按实际负载调大该值，而非降级字符集 - 单列索引长度限制：InnoDB 默认单列索引最大 767 字节（旧版本）或 3072 字节（启用
innodb_large_prefix）。utf8mb4下每个字符最多 4 字节，意味着VARCHAR(255)字段无法全量建索引 → 必须显式控制长度，例如VARCHAR(191) - 排序开销：使用
utf8mb4_unicode_ci时，字符串比较逻辑比latin1_swedish_ci复杂，但现代 CPU 上差异微乎其微；若业务对排序敏感（如高频 ORDER BY + LIMIT），可考虑utf8mb4_0900_as_cs（MySQL 8.0+），它更快且大小写敏感
字段定义必须配合字符集做约束
只改服务器字符集没用，字段级设计才是性能落脚点：
- 用户名、邮箱等固定短文本，别用
VARCHAR(255)，设为VARCHAR(64)或VARCHAR(128)—— 减少行长度，提升缓冲池利用率 - 状态码、类型标识等纯 ASCII 内容，优先用
BINARY(32)或CHAR(2)，避免字符集校验开销 - 全文搜索字段（如文章正文）若不需要排序/比较，可用
TEXT CHARACTER SET utf8mb4 COLLATE utf8mb4_bin，跳过 Unicode 规则，降低比较成本 - 所有
TEXT/VARCHAR字段加NOT NULL，NULL 标记会额外占用 1 字节/列，并干扰索引统计
迁移存量表时最常踩的坑
已有表从 utf8 升级到 utf8mb4 不是执行一条 ALTER TABLE ... CONVERT TO CHARACTER SET utf8mb4 就完事：
- 先查当前索引长度：
SHOW CREATE TABLE tbl_name，确认是否已超 767 字节；若VARCHAR(255)字段上有索引，必须先DROP INDEX，再MODIFY COLUMN缩短长度，最后重建索引 - 应用连接层必须同步改：PHP PDO 加
charset=utf8mb4，Pythonmysql-connector加charset='utf8mb4'，否则客户端仍以utf8发送，服务端会双重编码 - 检查
character_set_client、character_set_connection、character_set_results三个变量是否均为utf8mb4，可用SET NAMES utf8mb4统一设置
真正难的不是改配置，是让每个环节都“知道并遵守”utf8mb4——漏掉任意一环，数据就悄悄损坏了。
