对于UTF-8文本信息，应该使用utf8_general_ci，因为。。。

utf8_bin：按中每个字符的二进制值字符串utf8_general_ci：比较字符串使用通用语言规则和使用不区分大小写的比较

也就是说，它将使搜索和索引数据更快、更有效、更有用。

主要区别是排序精度（比较语言中的字符时）和性能。唯一特殊的是utf8_bin，它用于比较二进制格式的字符。

utf8_generalci比utf8_unicodeci稍快，但不太准确（用于排序）。特定语言utf8编码（如utf8_swedish_ci）包含额外的语言规则，这些规则使这些语言的排序最准确。大多数时候我使用utf8_unicode_ci（我更喜欢精确性而不是小的性能改进），除非我有充分的理由更喜欢特定的语言。

您可以在MySQL手册上阅读有关特定unicode字符集的更多信息-http://dev.mysql.com/doc/refman/5.0/en/charset-unicode-sets.html

实际上，您可能希望使用utf8_unicode_ci或utf8_general_ci。

utf8_general_ci通过去掉所有重音符号进行排序，并将其排序为ASCIIutf8_unicode_ci使用unicode排序顺序，因此可以在更多语言中正确排序

然而，如果您只是使用它来存储英文文本，那么它们应该不会不同。

排序规则影响数据的排序方式以及字符串之间的比较方式。这意味着您应该使用大多数用户期望的排序规则。

charset unicode文档中的示例：

utf8_general_ci也令人满意德语和法语，除了“ß”等于“s”，而不是“ss”。如果您可以接受应用程序，则应使用utf8_general_ci，因为它更快。否则，请使用utf8_unicode_ci，因为它更准确。

所以，这取决于您的预期用户群以及您需要正确排序的程度。对于英语用户群，utf8_general_ci应该足够了，对于其他语言，如瑞典语，已经创建了特殊的排序规则。

非常非常注意使用utf8_general_ci时可能出现的问题。

当使用utf8_general_ci排序规则时，MySQL不会区分select语句中的某些字符。这可能会导致非常严重的错误，尤其是涉及用户名的错误。根据使用数据库表的实现，此问题可能允许恶意用户创建与管理员帐户匹配的用户名。

这个问题至少在5.x早期版本中会暴露出来——我不确定这种行为后来是否发生了变化。

我不是DBA，但为了避免这个问题，我总是使用utf8 bin，而不是不区分大小写的bin。

下面的脚本通过示例描述了问题。

-- first, create a sandbox to play in
CREATE DATABASE `sandbox`;
use `sandbox`;

-- next, make sure that your client connection is of the same 
-- character/collate type as the one we're going to test next:
charset utf8 collate utf8_general_ci

-- now, create the table and fill it with values
CREATE TABLE `test` (`key` VARCHAR(16), `value` VARCHAR(16) )
    CHARACTER SET utf8 COLLATE utf8_general_ci;

INSERT INTO `test` VALUES ('Key ONE', 'value'), ('Key TWO', 'valúe');

-- (verify)
SELECT * FROM `test`;

-- now, expose the problem/bug:
SELECT * FROM test WHERE `value` = 'value';

--
-- Note that we get BOTH keys here! MySQLs UTF8 collates that are 
-- case insensitive (ending with _ci) do not distinguish between 
-- both values!
--
-- collate 'utf8_bin' doesn't have this problem, as I'll show next:
--

-- first, reset the client connection charset/collate type
charset utf8 collate utf8_bin

-- next, convert the values that we've previously inserted in the table
ALTER TABLE `test` CONVERT TO CHARACTER SET utf8 COLLATE utf8_bin;

-- now, re-check for the bug
SELECT * FROM test WHERE `value` = 'value';

--
-- Note that we get just one key now, as you'd expect.
--
-- This problem appears to be specific to utf8. Next, I'll try to 
-- do the same with the 'latin1' charset:
--

-- first, reset the client connection charset/collate type
charset latin1 collate latin1_general_ci

-- next, convert the values that we've previously inserted
-- in the table
ALTER TABLE `test` CONVERT TO CHARACTER SET latin1 COLLATE latin1_general_ci;

-- now, re-check for the bug
SELECT * FROM test WHERE `value` = 'value';

--
-- Again, only one key is returned (expected). This shows 
-- that the problem with utf8/utf8_generic_ci isn't present 
-- in latin1/latin1_general_ci
--
-- To complete the example, I'll check with the binary collate
-- of latin1 as well:

-- first, reset the client connection charset/collate type
charset latin1 collate latin1_bin

-- next, convert the values that we've previously inserted in the table
ALTER TABLE `test` CONVERT TO CHARACTER SET latin1 COLLATE latin1_bin;

-- now, re-check for the bug
SELECT * FROM test WHERE `value` = 'value';

--
-- Again, only one key is returned (expected).
--
-- Finally, I'll re-introduce the problem in the exact same 
-- way (for any sceptics out there):

-- first, reset the client connection charset/collate type
charset utf8 collate utf8_generic_ci

-- next, convert the values that we've previously inserted in the table
ALTER TABLE `test` CONVERT TO CHARACTER SET utf8 COLLATE utf8_general_ci;

-- now, re-check for the problem/bug
SELECT * FROM test WHERE `value` = 'value';

--
-- Two keys.
--

DROP DATABASE sandbox;

本质上，这取决于你如何看待字符串。

由于Guus强调的问题，我总是使用utf8_bin。在我看来，就数据库而言，字符串仍然只是一个字符串。字符串是一组UTF-8字符。一个字符有一个二进制表示，所以为什么它需要知道你使用的语言？通常，人们会为多语言站点的系统构建数据库。这就是使用UTF-8作为字符集的全部意义。我是一个有点纯粹的人，但我认为错误风险大大超过了索引可能带来的微小优势。任何与语言相关的规则都应该在比DBMS高得多的级别上执行。

在我的书中，“价值”在一百万年内永远不应该等于“价值”。

如果我想存储文本字段并进行不区分大小写的搜索，我将使用MYSQL字符串函数和PHP函数，如LOWER（）和PHP函数strtolower（）。

对于Guus强调的情况，我强烈建议使用utf8_unicode_cs（区分大小写，严格匹配，大多数情况下正确排序），而不是utf8_bin（严格匹配，不正确排序）。

如果要搜索字段，而不是匹配用户，则使用utf8_general_ci或utf8_unicode_ci。两者都不区分大小写，将失去匹配（“ß”等于“s”，而不是“ss”）。还有一些特定于语言的版本，如utf8_german_ci，其中丢失匹配更适合指定的语言。

[编辑-近6年后]

我不再推荐MySQL上的“utf8”字符集，而是推荐“utf8mb4”字符集。它们几乎完全匹配，但允许更多的unicode字符。

实际上，MySQL应该更新了“utf8”字符集和相应的排序规则，以匹配“utf7”规范，但取而代之的是，单独的字符集和各自的排序规则不会影响已使用其不完整的“utf9”字符集的存储指定。

公认的答案相当明确地建议使用utf8_unicode_ci，而对于很棒的新项目，我想讲述一下我最近的相反经验，以防节省任何人的时间。

因为utf8_general_ci是MySQL中Unicode的默认排序规则，所以如果您想使用utf8_Unicode_ci，那么您必须在很多地方指定它。

例如，所有客户端连接不仅有一个默认字符集（对我来说有意义），而且还有一个默认排序规则（即，对于unicode，排序规则将始终默认为utf8_general_ci）。

很可能，如果您对字段使用utf8_unicode_ci，则需要更新连接到数据库的脚本，以明确提及所需的排序规则，否则当您的连接使用默认排序规则时，使用文本字符串的查询可能会失败。

结果是，当将任何大小的现有系统转换为Unicode/utf8时，由于MySQL处理默认值的方式，您可能会被迫使用utf8_general_ci。

我发现这些整理图表很有用。http://collation-charts.org/mysql60/.但我不确定哪个是使用的utf8_general_ci。

例如，这里是utf8_swedish_ci的图表。它显示了它解释为相同的字符。http://collation-charts.org/mysql60/mysql604.utf8_swedish_ci.html

在数据库上载文件中，在任何行之前添加以下行：

SET NAMES utf8;

你的问题应该得到解决。