這兩個排序規則都用于UTF-8字符編碼.不同之處在于如何對文本進行排序和比較。
注意：既然MySQL 5.5.3，您應該使用utf8mb4而不是utf8..它們都是指Utf-8編碼，但是舊的編碼。utf8有一個特定于MySQL的限制，防止使用編號高于0xFFFD的字符。
準確度
utf8mb4_unicode_ci是基于Unicode標準進行排序和比較，它在非常廣泛的語言中進行精確排序。
utf8mb4_general_ci未能實現所有Unicode排序規則，這將導致在某些情況下(例如在使用特定語言或字符時)不受歡迎的排序。
性能
utf8mb4_general_ci比較和排序更快，因為它需要一系列與性能相關的快捷方式。
在現代服務器上，這種性能提升幾乎可以忽略不計。它是在服務器只占當今計算機CPU性能的很小一部分的時代設計的。
utf8mb4_unicode_ci，它使用Unicode規則進行排序和比較，在使用范圍廣泛的特殊字符時，使用了相當復雜的算法來正確排序。這些規則需要考慮到特定于語言的慣例；并不是每個人都按照我們所說的“字母順序”對字符進行排序。
就拉丁語(即“歐洲”)語言而言，Unicode排序和簡化排序沒有多大區別。utf8mb4_general_ci在MySQL中進行排序，但是仍然有一些不同之處：
在非拉丁語言，如亞洲語言或不同字母的語言中，可能有很多。更多Unicode排序與簡化排序的區別utf8mb4_general_ci分揀。適合性utf8mb4_general_ci將在很大程度上取決于所使用的語言。對于某些語言來說，這是相當不夠的。
你應該用什么？
幾乎可以肯定的是，沒有理由使用utf8mb4_general_ci現在，我們已經留下了CPU速度足夠低的問題，因此性能差異將是非常重要的。您的數據庫幾乎肯定會受到其他瓶頸的限制。
在非常特殊的情況下，性能上的差異是可以衡量的，如果是你，你可能已經知道了。如果您正在經歷緩慢的排序，那么在幾乎所有情況下，索引/查詢計劃都會出現問題。更改您的排序規則函數不應該在要排除故障的事情列表中占據很高的位置。
過去，有些人建議使用utf8mb4_general_ci除非準確的排序將是足夠重要，以證明性能成本。今天，性能成本幾乎已經消失，開發人員正在更加認真地對待國際化。
我還要補充的另一件事是，即使您知道您的應用程序只支持英語，它可能仍然需要處理人名，而人名通常包含在其他語言中使用的字符，在這些字符中，正確排序同樣重要。一切都使用Unicode規則有助于為非常聰明的Unicode用戶提供一種安心，即他們為使排序工作正常而付出了很大的努力。
