mysql 8.0默认使用utf8mb4不会拖慢性能，反而在正确配置下更快；性能问题源于隐式转换、索引截断或排序规则不匹配等错误用法，而非utf8mb4本身。
MySQL 8.0 默认用 utf8mb4 不会拖慢性能，反而在多数场景下更快——但前提是正确配置，否则可能因隐式转换、索引截断或排序规则变更引发实际降速。
utf8mb4 本身不比 utf8mb3 慢，慢的是错误的使用方式
每个字符最多占 4 字节是存储事实，不是运行时开销。InnoDB 对 utf8mb4 的处理已深度优化，只要字段定义合理、索引长度未超限、排序规则匹配，INSERT/SELECT 性能差异可忽略。真正出问题的往往是这些环节：
- 把原本
VARCHAR(255)的字段直接CONVERT TO CHARACTER SET utf8mb4，而没调大innodb_large_prefix或改用ROW_FORMAT=DYNAMIC，导致建索引失败或自动降级为前缀索引（如只索引前 191 字符），查起来变慢 - 连接层用
charset=utf8，服务端虽静默映射为utf8mb4，但字段仍是utf8，每次查询都触发隐式字符集转换，CPU 升高 - 升级后沿用旧的
utf8mb4_general_ci排序规则，而 MySQL 8.0 默认是utf8mb4_0900_ai_ci；后者对 Unicode 排序更准、Collation weight 计算更高效，但若应用依赖旧规则行为，强行切过去可能让 ORDER BY 结果变化、缓存失效、甚至触发全表扫描
索引长度限制是最大性能雷区
InnoDB 默认单列索引键长上限是 767 字节。utf8mb4 下一个字符最多占 4 字节，所以 VARCHAR(192) 就到顶了（192 × 4 = 768）。如果原表有 VARCHAR(255) CHARSET=utf8 并加了索引，直接转 utf8mb4 后，ALTER TABLE 会报错 Specified key was too long，除非提前开启 innodb_large_prefix = ON 并设 innodb_file_format = Barracuda。
更隐蔽的问题是：即使 ALTER 成功，InnoDB 可能悄悄把索引截成前缀（比如只存前 191 字符），导致 WHERE name = ? 无法走索引，变成全表扫描。
- 检查当前表索引长度：
SELECT table_name, column_name, character_maximum_length, character_octet_length FROM information_schema.columns WHERE table_schema = 'db_name' AND data_type IN ('varchar', 'text'); - 确认是否启用大前缀：
SHOW VARIABLES LIKE 'innodb_large_prefix';必须为ON - 建新表时显式指定：
CREATE TABLE t (name VARCHAR(191)) ROW_FORMAT=DYNAMIC;
排序规则切换带来真实性能波动
MySQL 8.0 默认排序规则从 utf8mb4_general_ci 升级为 utf8mb4_0900_ai_ci。后者基于 Unicode 12.1 标准，区分大小写、重音、变音更精确，但代价是 Collation weight 计算更复杂。
- 对纯 ASCII 字符（a-z, 0-9），两者性能几乎一致
- 对含重音符号的字段（如法语
café、西班牙语niño），_0900_ai_ci的比较耗时略高，但通常在微秒级，业务无感 - 真正影响大的是：旧应用假设
general_ci把ä和a当等价，切到_0900_ai_ci后不等价了，导致 WHERE 条件失效、ORDER BY 结果乱序、GROUP BY 分组崩塌——这不是慢，是逻辑错，排查时容易误判为“性能下降”
真正要盯住的不是“utf8mb4 是否变慢”，而是整条链路的字符集声明是否对齐：服务端变量、数据库/表/列定义、连接串参数、应用层编码设置。漏掉任意一环，都可能让 emoji 存不进、索引用不上、排序结果飘、查询计划歪——这些才是影响性能的硬伤。
