MariaDB 11切换utf8mb4_unicode_ci后性能下降，是否该用utf8mb4_general_ci？

1. 性能下降现象是否正常？ #

完全正常，核心原因是utf8mb4_unicode_ci与utf8mb4_general_ci的排序逻辑差异：

• utf8mb4_general_ci是简化排序规则，通过快速字符映射实现比较，计算开销极低，适合对排序精度要求不高的场景。
• utf8mb4_unicode_ci遵循Unicode标准排序规则，支持多语言重音字符、特殊符号的精准排序，计算逻辑复杂，资源开销远高于前者。

你遇到的具体问题诱因：

• 原有索引基于utf8mb4_general_ci创建，表/字段切换到utf8mb4_unicode_ci后，索引排序规则与当前字段规则不匹配，MariaDB无法直接复用索引，只能走全表扫描或低效转换，导致查询耗时飙升。
• 大表的ORDER BY/GROUP BY操作需要基于新规则重新计算排序逻辑，unicode_ci的高开销在大数据量下会导致资源耗尽，进而查询无法完成。

2. 将所有表设为utf8mb4_general_ci是否可行？ #

可行性取决于业务需求：

• 若业务对排序精度要求不高（仅处理中文、英文，无需严格区分重音字符、特殊符号的排序），完全可行。utf8mb4_general_ci性能优异，能覆盖绝大多数普通业务场景，还能避免规则切换引发的索引失效问题。
• 若业务需要严格符合Unicode标准排序（比如多语言国际业务，需正确处理重音字符排序），则不可行。utf8mb4_general_ci会简化字符映射，可能导致排序结果不符合业务预期（例如将é和e视为相同字符）。

3. 混合排序规则的场景建议 #

单表切换规则后性能提升是预期结果，但混合规则存在长期隐患：

• 跨表比较必须显式指定排序规则，增加SQL复杂度，容易遗漏引发隐式转换，进而导致索引失效或排序错误。
• 后续维护成本高，新增表、字段时易出现规则不一致，排查问题难度大。

如果暂时无法全量切换，建议：

• 优先将核心查询涉及的所有表统一为同一规则（要么全general_ci，要么全unicode_ci），避免跨表显式指定规则的麻烦。
• 若选择保留unicode_ci，需重新创建基于utf8mb4_unicode_ci的索引，替换原有索引，才能恢复索引使用效率。

内容的提问来源于stack exchange，提问作者Dimas