为什么 MySQL 在使用带有通配符的 LIKE 运算符时会忽略假名敏感？答案

【问题标题】：Why does MySQL ignore kana-sensitive when using the LIKE operator with a wildcard?为什么 MySQL 在使用带有通配符的 LIKE 运算符时会忽略假名敏感？
【发布时间】：2023-04-04 01:33:01
【问题描述】：

当我搜索 LIKE %カナ 时，它仍然会显示かな的结果。

来自Language-Specific Collations 下的 MySQL 文档（我在 8.0.26）：

对于日语，utf8mb4 字符集包括 utf8mb4_ja_0900_as_cs 和 utf8mb4_ja_0900_as_cs_ks 排序规则。两种排序规则都区分重音并且区分大小写。 utf8mb4_ja_0900_as_cs_ks 也是假名敏感和区分的片假名字符来自平假名字符，而utf8mb4_ja_0900_as_cs 对待片假名和平假名字符相等，便于排序。

检查我的专栏，它显示了对假名敏感的排序规则：

SELECT COLUMN_NAME, COLLATION_NAME FROM INFORMATION_SCHEMA.COLUMNS;

COLUMN_NAME	COLLATION_NAME
kana	`utf8mb4_ja_0900_as_cs_ks`

【问题讨论】：

标签： mysql collation cjk

【解决方案1】：

MySQL 使用三种（？）不同的代码进行字符比较：=、LIKE、REGEXP。令人困惑的是，它们并不完全相同。在某些情况下，它们是故意不同的。

s LIKE 'abc' 变成了s = 'abc'，更加混乱了。

以_as_cs 结尾的排序规则意味着'e' <> 'E'，但无论< 或> 是否适用，仍然可以使用。这与 BINARY 或 _bin 排序规则不同，在这种情况下，它会盲目检查位。

您使用的排序规则相对较新；它不早于 8.0。如果您在排序规则中发现错误，请在 bugs.mysql.com 提交错误报告并提供一个简单的测试用例来证明该问题。

【讨论】：

【解决方案2】：

如果区分大小写，请尝试使用 LIKE BINARY。

例子：

SELECT name FROM users WHERE name LIKE BINARY 'John%';

【讨论】：

请注意，我问的是假名敏感性。这可行，但我的问题是为什么它不能按原样使用 LIKE 和通配符，因为根据列排序规则，其中一个操作数对假名敏感。不使用LIKE 或删除通配符按预期工作。区分大小写的模拟测试也可以按预期工作，无需 BINARY 覆盖。