高utf-8码点的MySQL比较问题

Question

我看到了MySQL和非常高的UTF8代码点的奇怪行为。

几个示例( -> \u{1f48f}或\u{1f48e}或其他任何东西)

SELECT name, '', name = '', '' = '', name = '' from payees where id = 4178417368;
+------+------+-------------+-----------+-----------+
| name |    | name = '' | '' = '' | name = '' |
+------+------+-------------+-----------+-----------+
|      |  | 1           | 0         | 1         |
+------+------+-------------+-----------+-----------+
1 rows in set (0.04 sec)

请注意，相等已变为不可传递的: name等于空字符串，name等于随机字符，但随机字符不等于空字符串。

当然，这是在相当旧的MySQL 5.1.68版本上实现的。有没有人知道，在MySQL 5.1或5.x的新版本中仍然是这样的？

Answer 1

utf8字符集仅支持基本多语言平面( MySQL )中的字符。它不支持补充平面中的任何字符。

参考：http://dev.mysql.com/doc/refman/5.5/en/charset-unicode-utf8.html

支持4字节编码的utf8mb4字符集引入了MySQL 5.5.x；utf8字符集的行为保持不变。

http://dev.mysql.com/doc/refman/5.5/en/charset-unicode-utf8mb4.html

从您发布的内容可以看出，存储在该行的name列中的值是一个长度为零的字符串。(您可以使用LENGTH(名称)、CHAR_LENGTH(名称)、HEX(名称)函数来更好地了解实际存储在其中的内容。

将name列与空字符串和不受支持的字符进行相等比较看起来应该返回1。

但是两个返回0的文字的比较结果，我真的没有预料到。其中不涉及列字符集，因此将仅为客户端字符集。我很想对该文本使用LENGTH、CHAR_LENGTH和HEX函数。

这些文字的比较结果要么是1)记录的行为(在某个地方记录的)，要么是2)未定义的行为，并且MySQL可以做它所做的任何事情，或者3)它是一个错误(即，该行为偏离了记录的行为)。