选择字符集应根据业务需求权衡存储、内存和查询效率，utf8mb4支持完整Unicode但开销大，latin1节省空间适合纯英文，不合理选择会增加I/O、内存压力及CPU开销，影响高负载性能。
MySQL安装时选择字符集对性能有一定影响，但更多体现在存储空间、内存使用和查询效率上，而非直接决定整体性能。关键在于根据实际业务需求合理选择字符集，避免不必要的资源浪费。
字符集与存储开销
字符集决定了每个字符占用的字节数，直接影响数据存储大小：
- utf8mb4：支持完整的Unicode（包括emoji），每个字符最多占用4字节
- utf8（MySQL中的别名，实际为utf8mb3）：每个字符最多3字节，不支持四字节字符（如某些表情符号）
- latin1：仅支持西欧字符，每个字符固定1字节，存储最省空间
如果使用utf8mb4存储大量ASCII文本（如英文日志），相比latin1会多占用3倍存储空间，进而增加磁盘I/O、缓冲池压力和备份时间。
内存与缓存效率
MySQL的InnoDB缓冲池、排序操作、临时表等都受字符集影响：
- 相同内容在utf8mb4下占用更多内存，可能导致缓冲池命中率下降
- 排序和比较操作需按字符集规则处理，utf8mb4的排序规则（如utf8mb4_unicode_ci）比latin1复杂，CPU开销略高
- 临时表若使用utf8mb4且涉及大量JOIN或ORDER BY，可能触发磁盘临时表，显著降低性能
索引长度与结构限制
字符集影响索引的最大长度：
- InnoDB单列索引最大767字节（旧版本）或3072字节（开启innodb_large_prefix）
- 使用utf8mb4时，每个字符最多4字节，意味着最多约191个字符可被索引（767/4）
- 若字段较长（如VARCHAR(255)），可能无法完整建立索引，导致前缀索引或索引失效，影响查询性能
实际建议
选择字符集应权衡功能与性能：
- 需要支持中文、emoji或多语言 → 使用utf8mb4 + utf8mb4_unicode_ci
- 纯英文或拉丁字符环境 → 可选latin1或ascii，节省资源
- 避免在不需要的情况下强制使用utf8mb4，尤其对大字段和高并发场景
- 合理设置collation，避免在查询中出现隐式转换，影响索引使用
基本上就这些。字符集本身不会让MySQL变快或变慢很多，但不合理的选择会在高负载下放大问题。关键是匹配业务需求，同时注意字段设计和索引策略。不复杂但容易忽略。
