通用字符存储场景下utf8mb4表排序规则选择咨询

刚好之前做过支持多语言的后端存储优化，来给你捋捋这些排序规则的门道，帮你快速选到合适的：

一、那些“特定排序规则”到底有啥用？ #

说白了，不同的排序规则就是对应不同语言的排序、字符匹配逻辑，举几个常见的例子：

• 德语专属的utf8mb4_de_pb_0900_ai_ci：会把德语里的ß和ss视为等价字符，查询时能匹配到，排序也符合德语用户的习惯；
• 西班牙语的utf8mb4_es_0900_ai_ci：会把ñ和普通的n当作不同字符排序，不会混在一起；
• 阿拉伯文的utf8mb4_ar_0900_ai_ci：严格遵循阿拉伯文从右到左的排序逻辑，还有特定字母的优先级规则，适合面向阿拉伯地区的业务；
• 还有带_cs（区分大小写）、_as（区分重音）后缀的规则，比如utf8mb4_general_cs，适合需要严格区分大小写的场景（比如用户名）；极端点的utf8mb4_bin是二进制排序，完全按字符的Unicode码点比较，不考虑任何语言规则。

这些特定规则的核心作用就是让数据库的排序、查询匹配符合对应语言的用户直觉，提升特定地区用户的使用体验。

二、utf8mb4_general_ci和utf8mb4_unicode520_ci能覆盖所有场景吗？ #

答案是：大部分通用场景可以，但不是100%覆盖

• utf8mb4_general_ci：属于早期的通用规则，排序逻辑比较简单，对很多语言的特殊字符处理不够精准（比如德语的ß会被当成s，西班牙语的ñ和n混排），优点是性能略好一点，但现在数据库优化后这个差距基本可以忽略；
• utf8mb4_unicode520_ci：基于Unicode 5.2标准，支持的语言规则更多，排序更精准，能处理中文、英文、阿拉伯文等主流语言的基础排序需求，是通用多语言场景的首选。

但如果你的业务有特定语言的严格要求（比如做德语电商的商品排序、阿拉伯文新闻的专业排版），或者需要严格区分大小写/重音，那这两个通用规则就不够用了，得选对应语言的特定规则。

三、存储中文到阿拉伯文的多语言字符，选哪个？ #

分两种情况：

1. 通用多语言场景，无特定语言的特殊排序需求：直接选utf8mb4_unicode520_ci就够了。它对中文的拼音/Unicode排序支持很好，阿拉伯文的基础排序也能正确处理，兼顾了大部分主流语言的用户习惯，不会出现明显的违和感；
2. 有阿拉伯文专业需求（比如面向阿拉伯地区用户，需要严格遵循当地排序规范）：可以选utf8mb4_ar_0900_ai_ci，它是基于Unicode 9.0的阿拉伯文专用规则，排序更贴合当地用户的使用习惯。

另外补充：如果需要严格区分字符的大小写、重音（比如某些系统的用户名要求区分大小写），可以选带_cs后缀的规则，或者utf8mb4_bin，但普通业务场景不建议用utf8mb4_bin，因为它完全不考虑语言规则，用户查询时会觉得不符合直觉。

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