我正在进行一些查询调试，并发现在将varchar字段与文字进行比较时，我得到了意外（虽然显然是正确的）TRUE。具体如下：
insert into comp_test(test_string) values('TestString'); where test_string='tESTsTRING'条款为真where test_string='TestString '子句为真（在末尾用空格填充）因此，在构建我的问题时，我可以在一个类似的post帖子中描述原因以及如何强制区分大小写（使用BINARY和COLLATE等）。 BINARY和COLLATE解决方案是否也会导致空白填充使该子句失败？
我现在有部分解决方案，但任何人都可以解释为什么等价比较如此草率？在上面的情况下，如果test_string中的值是一个8字符的字符串，那么有大约64,000个文字将导致比较评估为true。那是什么样的等价？这似乎是错误的，几乎所有其他语言都不会允许任何东西，只有1比1的等值。
提前致谢。
答案 0 :(得分：1)
尽管有像C和FORTRAN这样的老式语言以及像Oracle这样的老式DMBS系统，MySQL的内置字符串整理系统允许最终用户指定特定于语言的整理规则。 （顺便说一句，在Java和DotNet等系统中进行字符串处理。）
这是一个非常酷的功能。它允许您为许多不同的语言排序适当的按字母顺序排列（===整理）规则。
您可以发出此搜索条款以获得所需的匹配类型。
WHERE BINARY test_string = 'TestString '
或
WHERE test_string = 'TestString ' COLLATE utf8_bin
或
WHERE test_string = 'TestString ' COLLATE utf8_swedish_ci
如果您的数据恰好是瑞典语并存储在UTF8字符集中。
请参阅http://dev.mysql.com/doc/refman/5.5/en/charset-collate.html
但你需要小心这一点。如果要求WHERE子句中的排序规则与表中的排序规则不匹配，则SQL可能运行效率低下。
最好使用正确的字符集和排序规则声明列。如果您这样做，那么您的表索引将被设置为快速获取您需要的数据。如果您的数据确实是二进制数据（只有您知道），您可以使用
声明表格或列 COLLATE BIN
改性剂。
这部分MySQL值得您努力弄清楚。