为什么MySQL使用带通配符的LIKE运算符时会忽略假名敏感设置？

问题原因与解决方法 #

该问题通常由两类配置偏差导致，可按以下顺序排查修复：

1. 查询字面量排序规则未与列对齐

MySQL执行LIKE匹配时，会优先采用运算符两端优先级更高的排序规则作为匹配依据。你写的%カナ查询字面量默认继承当前数据库连接的排序规则，若连接级排序规则不是假名敏感类型，就会导致匹配时忽略平假名、片假名差异。
你可以先执行以下命令验证当前会话中常量字符串的排序规则：

SELECT COLLATION('%カナ');

如果返回结果不是utf8mb4_ja_0900_as_cs_ks，任选一种方式修复即可：

• 单次查询显式指定排序规则：

SELECT * FROM 你的表名 WHERE kana LIKE '%カナ' COLLATE utf8mb4_ja_0900_as_cs_ks;

• 调整当前连接的全局排序规则，后续查询自动生效：

SET NAMES utf8mb4 COLLATE utf8mb4_ja_0900_as_cs_ks;

2. 修改列排序规则时未转换历史数据

如果你是先插入数据，之后才修改的列排序规则，且修改时未执行字符集转换，历史数据的编码权重仍然沿用旧规则，也会导致匹配异常。
执行以下命令重新转换列编码，同步更新历史数据即可修复：

ALTER TABLE 你的表名 MODIFY COLUMN kana [你的字段原有类型] CHARACTER SET utf8mb4 COLLATE utf8mb4_ja_0900_as_cs_ks;
-- 示例：字段为VARCHAR(50) NOT NULL时的语句
-- ALTER TABLE user MODIFY COLUMN kana VARCHAR(50) NOT NULL CHARACTER SET utf8mb4 COLLATE utf8mb4_ja_0900_as_cs_ks;

规则有效性验证

你可以通过以下测试确认排序规则本身正常生效：

CREATE TABLE test_kana (
  kana VARCHAR(10) COLLATE utf8mb4_ja_0900_as_cs_ks
);
INSERT INTO test_kana VALUES ('カナ'), ('かな');
-- 执行后仅返回「カナ」一条记录即为正常
SELECT * FROM test_kana WHERE kana LIKE '%カナ' COLLATE utf8mb4_ja_0900_as_cs_ks;

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