一般来说，* utf8_general_ci * 比 * utf8_unicode_ci * 快，但不太正确。
区别在于：
对于任何Unicode字符集，使用_general_ci归类执行的操作都比使用_unicode_ci归类执行的操作快。例如，utf8_general_ci归类的比较比utf8_unicode_ci归类的比较快，但准确性稍差。这是因为utf8_unicode_ci支持扩展等Map;即，当一个字符与其他字符的组合进行比较时。例如，在德语和某些其他语言中，"ß"等于"ss"。utf8_unicode_ci还支持缩写和可忽略字符。utf8_general_ci是不支持扩展、缩写或可忽略字符的旧归类。它只能在字符之间进行一对一比较。
引自：http://dev.mysql.com/doc/refman/5.0/en/charset-unicode-sets.html
要了解更详细的解释，请阅读MySQL论坛上的以下帖子：http://forums.mysql.com/read.php?103,187048,188748
对于utf8_bin：* utf8_general_ci * 和 * utf8_unicode_ci * 都执行不区分大小写的比较。相比之下，utf8_bin区分大小写（还有其他区别），因为它比较字符的二进制值。

您还应该注意到，使用utf8_general_ci时，当使用varchar字段作为唯一索引或主索引时，插入2个值如'a'和'á'会给予重复键错误。

• utf8_bin盲目地比较位。没有大小写折叠，没有重音剥离。
• utf8_general_ci比较一个码点与另一个码点。它进行大小写折叠 * 和 * 重音剥离，但不进行2字符比较;例如：在此归类中，ij不等于ij。
• utf8_*_ci是一组特定于语言的规则，但在其他方面与unicode_ci相似。x1米6英寸1x、x1米7英寸1x、x1米8英寸1x、x1米9英寸1x
• utf8_unicode_ci遵循旧的Unicode标准进行比较。ij = ij，但ae!= æ
• utf8_unicode_520_ci遵循较新的Unicode标准。ae = æ

参见collation chart，了解在各种utf8归类中什么等于什么的细节。
utf8，* 由MySQL * 定义，仅限于1到3字节的utf8代码。这就排除了Emoji和一些中文。所以如果你想走出欧洲，你真的应该改用utf8mb4。
以上几点适用于utf8mb4，但需要进行适当的拼写更改。今后，首选utf8mb4和utf8mb4_unicode_520_ci。或者（在8.0中）utf8mb4_0900_ai_ci

• UTF16和UTF32是UTF8的变体;它们实际上是没有用处的。
• ucs2比"utf8"更接近"Unicode";它实际上是没有用处的。

接受的答案已过期。
如果您使用MySQL 5.5.3+，请使用utf8mb4_unicode_ci而不是utf8_unicode_ci，以确保用户键入的字符不会给您带来错误。
例如，utf8mb4支持表情符号，而utf8可能会给您带来数百个与编码相关的错误，如：
Incorrect string value: ‘\xF0\x9F\x98\x81…’ for column ‘data’ at row 1

实际上，我测试了在具有unique索引的列中保存'é'和'e'这样的值，它们在'utf8_unicode_ci'和'utf8_general_ci'上都导致重复错误。您只能将它们保存在'utf8_bin'排序列中。
mysql文档（http://dev.mysql.com/doc/refman/5.7/en/charset-applications.html中）建议在其示例中设置“utf8_general_ci”排序规则。

[mysqld]
character-set-server=utf8
collation-server=utf8_general_ci