使用BINARY运算符时MySQL正则表达式词边界检测与德语变音符号问题

这个现象确实是MySQL在处理BINARY运算符结合正则词边界时的特殊行为，核心问题出在二进制字符串与普通字符串的词边界判断逻辑差异上：

问题重现 #

先确认你的测试查询结果：

SELECT 'Konzessionäre' REGEXP '[[:<:]]Konzession[[:>:]]'; -- 结果为0（符合预期，Konzession是前缀，无独立词边界）
SELECT BINARY 'Konzessionäre' REGEXP '[[:<:]]Konzession[[:>:]]'; -- 结果为1（不符合预期）

根本原因 #

1. 非BINARY模式的词边界判断
   没有BINARY时，MySQL会基于当前连接的字符集和排序规则（比如utf8mb4_german2_ci这类德语专属规则）识别单词字符。德语变音符号ä会被归类为单词字符的一部分，所以Konzessionäre被视为一个完整单词，Konzession只是它的前缀，不存在独立的词边界[[:>:]]，因此匹配失败返回0。

2. BINARY模式的词边界判断
   BINARY会把字符串转换为二进制字节流，此时MySQL的正则词边界判断切换到字节层面。ä在UTF-8中是两个独立字节（0xC3 0xA4），这两个字节会被判定为非单词字符（二进制下仅字母、数字、下划线属于单词字符）。所以Konzession的末尾字节与ä的第一个字节之间，会被识别为词边界[[:>:]]，导致整个正则匹配成功，返回1。

替代解决方案 #

如果需要大小写敏感的匹配，但不想破坏字符层面的词边界逻辑，别用BINARY运算符，改用大小写敏感的排序规则实现：

SELECT 'Konzessionäre' COLLATE utf8mb4_bin REGEXP '[[:<:]]Konzession[[:>:]]';

这个查询既保留了字符层面的词边界判断，又实现了大小写敏感匹配，结果会返回0，符合预期。

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