无法找到肯定存在的“=”操作的行答案

【问题标题】：Unable to find row with "=" operation that certainly exists无法找到肯定存在的“=”操作的行
【发布时间】：2016-09-12 10:48:28
【问题描述】：

以下语句返回空集。

SELECT id,field_DOMid FROM korektura WHERE field_DOMid = 'vyznam-1284--vyklad_vyznamu' ORDER BY cts DESC LIMIT 1;

但是看LIKE的结果（值是有的）：

任何人都可以提出可能导致这种行为的原因吗？是MySQL服务器问题，排序问题？（我们在 collations/index.xml 中使用为 UTF8 字符集定义的自定义排序规则）

没有尾随空格：

mysql> SELECT field_DOMid, CHAR_LENGTH(field_DOMid),  CHAR_LENGTH(TRIM(field_DOMid)) FROM korektura WHERE id=27580;
 +-----------------------------+--------------------------+--------------------------------+
| field_DOMid                 | CHAR_LENGTH(field_DOMid) | CHAR_LENGTH(TRIM(field_DOMid)) |
+-----------------------------+--------------------------+--------------------------------+
| vyznam-1284--vyklad_vyznamu |                       27 |                             27 |
+-----------------------------+--------------------------+--------------------------------+
1 row in set (0.00 sec)

更重要的是，MySQL 文档说：

所有 MySQL 排序规则都是 PADSPACE 类型。这意味着在比较 MySQL 中的所有 CHAR、VARCHAR 和 TEXT 值时，不考虑任何尾随空格。

提前致谢！

【问题讨论】：

值是否以空格开头？
不幸的是，情况可能并非如此。检查更新的答案。
让我们看看LENGTH()（字节数）和HEX()。
请提供SHOW CREATE TABLE korektura。
什么版本的mysql或mariadb？

标签： mysql mariadb

【解决方案1】：

我能想到的唯一原因是“vyznam”之前是否有空格或换行符。尝试检查。

【讨论】：

不幸的是，情况可能并非如此。检查更新的答案。

【解决方案2】：

如果有人遇到这样的问题，我的解决方案是重建索引（表）：

mysqldump db_name > dump.sql
mysql db_name < dump.sql

或使用此处描述的其他方法：https://dev.mysql.com/doc/refman/5.7/en/rebuilding-tables.html

【讨论】：

OPTIMIZE TABLE tablename 是重建索引的更简单方法。
我想重建所有 172 个表，因此采用 mysqldump 解决方案。

【解决方案3】：

试试这个查询进行调试：

SELECT field_DOMid, LENGTH(field_DOMid), LENGTH(TRIM(field_DOMid)) , CHAR_LENGTH(field_DOMid),  CHAR_LENGTH(TRIM(field_DOMid)) FROM korektura WHERE id=27580;

如果LENGTH() 返回超过 27，则意味着第一个字符可能是用两字节字符编码的（这在 UTF-8 中是合法的）。因此，如果您想将其与文字字符串进行匹配，则必须先 convert 它：

SELECT id,field_DOMid FROM korektura WHERE field_DOMid = convert('vyznam-1284--vyklad_vyznamu' using utf8) ORDER BY cts DESC LIMIT 1;

【讨论】：