1

我正在做一些查询调试，发现在将 varchar 字段与文字进行比较时，我得到了意想不到的（虽然显然是正确的）TRUE。具体如下：

  • 有问题的行只是一个自动增量 int 主键和一个 varchar(255)
  • 设置添加单行：insert into comp_test(test_string) values('TestString');
  • where test_string='tESTsTRING'子句为真
  • where test_string='TestString '子句为真（最后用空格填充）

因此，在构建我的问题时，我可以在一篇类似的帖子中描述原因以及如何强制区分大小写（使用 BINARY 和 COLLATE 等）。BINARY 和 COLLATE 解决方案是否也会导致空白填充使子句为假？

我现在有了部分解决方案，但谁能解释为什么等价比较如此草率？在上述情况下，如果 test_string 中的值是 8 个字符的字符串，则大约有 64,000 个文字会导致比较结果为真。那是什么样的等价物？这似乎是错误的，几乎所有其他语言都不会允许除 1 对 1 等价外的任何东西。

提前致谢。

4

1 回答 1

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-collat​​e.html

但是你需要小心这个。如果您在 WHERE 子句中要求的排序规则与表中的排序规则不匹配，则您的 SQL 可能运行效率低下。

最好使用正确的字符集和排序规则声明您的列。如果你这样做，那么你的表索引将被设置为快速获取你需要的数据。如果您的数据确实是二进制数据（只有您知道），您可以使用

  COLLATE BIN

修饰符。

MySQL 的这一部分值得你努力去弄清楚。

于 2012-05-24T16:10:22.717 回答