我正在使用django应用程序执行一些“启动”ORM操作，将longtext列与unicode字符串进行比较。这导致LIKE BINARY比较操作与u'mystring' unicode字符串。 LIKE BINARY可能比普通的LIKE慢吗？
我知道一般的答案是基准测试，但我想得到一般的数据库概念，而不仅仅是我的应用程序，因为我之前从未见过LIKE BINARY查询。
我碰巧使用的是MySQL，但我对SQL数据库的答案感兴趣。
答案 0 :(得分：5)
如果性能似乎成为一个问题，可能是创建第一个例如的副本的好主意。 longtext的255个字符，在其上添加索引并使用startswith。
BTW，this page says：“如果需要进行区分大小写的匹配，请将列声明为BINARY;不要在查询中使用LIKE BINARY来转换非二进制列。如果这样做，请执行MySQL不会在该列上使用任何索引。“这是一个旧的提示，但我认为这仍然有效。
答案 1 :(得分：2)
对于遇到此问题的下一个人 - 在我们相对较小的数据库中查询：
SELECT * FROM table_name WHERE field LIKE 'some-field-search-value';
... Result row
Returns 1 row in set (0.00 sec)
与：相比：
SELECT * FROM table_name WHERE field LIKE BINARY 'some-field-search-value';
... Result row
Returns 1 row in set (0.32 sec)
长话短说，至少对于我们的数据库（MySQL 5.5 / InnoDB），两次查找之间的性能存在非常显着的差异。
显然虽然这是MySQL 5.5中的一个错误：http://bugs.mysql.com/bug.php?id=63563，在我对MySQL 5.1中同一个数据库的测试中，LIKE BINARY查询仍然使用索引（而在5.5中则执行全表扫描。）< / p>
答案 2 :(得分：0)
技巧：如果您不想将列的类型更改为二进制，请尝试编写 WHERE语句，如下所示：
WHERE field = 'yourstring' AND field LIKE BINARY 'yourstring'
代替：
WHERE field LIKE BINARY 'yourstring'
实际上，它将很快检查第一个条件，只有在第一个条件为真时才尝试第二个条件。
在我的项目中，此平等测试效果很好，我认为您可以使其适应“从头开始”测试。