utf8mb4_unicode_ci编码下MySQL查询Hüsby返回错误结果Husby的排查求助

这个问题其实是因为utf8mb4_unicode_ci排序规则的设计特性导致的——它会将带变音符号的字符（比如ü）和对应的基础字符（u）视为相等，所以查询Hüsby会匹配到Husby。如果需要严格区分这两个字符串，你可以从以下几个方向排查和调整：

• 改用区分变音符号的排序规则
  你可以为Ort字段更换为更严格的排序规则，比如：

  • utf8mb4_bin：二进制比较，严格区分每个字符的编码值，完全匹配才会返回结果
  • utf8mb4_unicode_520_ci：基于Unicode 5.20标准，比utf8mb4_unicode_ci更严格，会区分部分变音字符
  • 针对德语的排序规则（比如utf8mb4_de_pb_0900_ai_ci）：更贴合德语语言特性，能正确区分变音和基础字符
    修改字段排序规则的语句示例：

  ALTER TABLE stammdaten MODIFY COLUMN Ort VARCHAR(255) CHARACTER SET utf8mb4 COLLATE utf8mb4_bin;
  

• 检查连接层的字符集与排序规则
  有时候客户端连接使用的排序规则会覆盖表的设置，导致查询时用了不区分变音的规则。你可以先查看当前连接的排序规则：

  SHOW VARIABLES LIKE 'collation_connection';
  

  如果发现不是你需要的规则，可以临时修改测试：

  SET collation_connection = 'utf8mb4_bin';
  

  也可以在数据库连接字符串中指定排序规则（比如JDBC连接添加&collation=utf8mb4_bin），确保连接层使用正确的规则。

• 验证数据的实际存储状态
  先确认数据库里确实存储了Hüsby而不是插入时就被转成了Husby。可以通过十六进制编码来验证：

  SELECT Ort, HEX(Ort) FROM stammdaten WHERE Ort IN ('Husby', 'Hüsby');
  

  正常情况下，Hüsby的ü对应的十六进制是C3BC，而Husby的u是75，如果两者的十六进制相同，说明数据插入时就出现了转换问题，需要检查插入数据时的字符集设置。

• 在查询中强制指定排序规则
  不需要修改表结构，你可以在单个查询中用COLLATE子句强制使用严格匹配的规则，快速验证效果：

  SELECT Ort FROM stammdaten WHERE Ort = 'Hüsby' COLLATE utf8mb4_bin;
  

  如果这个查询能正确返回Hüsby（而不是Husby），说明排序规则是核心问题。

• 检查MySQL版本
  旧版本的MySQL（比如5.7之前）对某些Unicode排序规则的实现可能存在缺陷，升级到较新的版本（比如8.0系列）可能会解决一些字符匹配的异常问题。

内容的提问来源于stack exchange，提问作者Thomas Kujawa