一些细节(PL)

正如我们可以在这里(Peter Gulutzan)读到的，排序/比较波兰字母“Ł”(L与笔画- html esc: Ł)(小写:“ova”- html esc: ł) -我们有以下假设:

utf8_polish_ci      Ł greater than L and less than M
utf8_unicode_ci     Ł greater than L and less than M
utf8_unicode_520_ci Ł equal to L
utf8_general_ci     Ł greater than Z

在波兰语中，字母Ł在字母L之后，在字母m之前，没有哪个编码更好或更差——这取决于你的需要。

根据这篇文章，在MySQL 5.7上使用utf8mb4_general_ci而不是utf8mb4_unicode_ci有相当大的性能优势: https://www.percona.com/blog/2019/02/27/charset-and-collation-settings-impact-on-mysql-performance/

这篇文章描述得很好。

简而言之:utf8_unicode_ci使用Unicode标准中定义的Unicode排序算法，而utf8_general_ci是一种更简单的排序顺序，会导致“不太准确”的排序结果。

简单来说:

如果您需要更好的排序顺序-使用utf8_unicode_ci(这是首选方法)，

但是如果您对性能非常感兴趣，可以使用utf8_general_ci，但要知道它有点过时了。

性能方面的差异非常微小。

排序和字符匹配有两个很大的区别:

排序:

Utf8mb4_general_ci删除所有重音并逐个排序，这可能会产生不正确的排序结果。 Utf8mb4_unicode_ci排序准确。

字符匹配

它们以不同的方式匹配字符。

例如，在utf8mb4_unicode_ci中，你有i !=伊斯坦布尔，但在utf8mb4_general_ci中，它包含了伊斯坦布尔=伊斯坦布尔。

例如，假设您有一个name=" yilmaz "的行。然后

select id from users where name='Yilmaz';

如果搭配为utf8mb4_general_ci，则返回该行，但如果搭配为utf8mb4_unicode_ci，则不会返回该行!

另一方面，我们在utf8mb4_unicode_ci中有a=ª和ß=ss，而在utf8mb4_general_ci中则不是这样。所以想象你有一行的名字="ªßi"，然后

select id from users where name='assi';

如果并置为utf8mb4_unicode_ci则返回行，但如果并置设置为utf8mb4_general_ci则不返回行。

每个搭配的完整列表可以在这里找到。

上面的注释表明没有理由使用utf8_general*。然而，对于日本人来说，这可能不是真的。

在MariaDB中，utf8mb4_ja_0900_as_cs不可用，因此必须使用unicode或通用选项之一。然而，unicode对待浊音和浊音等是一样的。例如，びよういん(美容师)被视为等同于びょういん(医院)。这显然是不正确的行为。

> select strcmp('が', 'か' collate utf8mb4_unicode_ci); #0
> strcmp('びよういん', 'びょういん' collate utf8mb4_unicode_520_ci); #0 

而将军给出

> select strcmp('が', 'か' collate utf8mb4_general_ci); #1

换句话说，unicode对浊音假名和浊音假名一视同仁。在我看来，这并不可取。

编辑:使用uca1400_ai_cs可能更好，它在MariaDB的新版本中可用，并使上述排序正确。