我绝对不知道为什么，但是三重转义会有所帮助！
好吧，这只是双重转义，但是是可行的，原因如下：在MySQL中，使用
LIKE运算符时涉及第二层转义。
services LIKE '%L\\u00e4mm\\u00f6n%'
解析该MySQL字符串文字可以使您与LIKE-query进行比较
%L\u00e4mm\u00f6n%。由于MySQL
在LIKE查询中将其视为转义符，因此实际上将匹配包含的文字字符串
Lu00e4mmu00f6n。
这样做的原因是，您可以将字符串与包含文字
%或
_字符的查询表达式进行匹配。例如，如果我想在列中搜索文字字符串
100%，则可以将其与
100%（在查询中写为
'100\%'）相匹配，并确保我真的得到了百分之一百，而不是任何以一百开头的字符串。
不幸的是，MySQL在其LIKE查询转义和字符串文字转义中都使用了反斜杠，特别是考虑到您可能正在使用也使用它们的封闭式编程语言进行编写，最后以实际的三重编码结束了，看起来像
"servicesLIKE '%L\\\\u00e4mm\\\\u00f6n%'"-argh！
鉴于这种行为不符合ANSI SQL，并且在其他任何数据库中均不起作用，这是非常不幸的。ANSI
SQL表示默认情况下，LIKE查询中没有转义字符，因此，如果您要匹配文字，
%或者
_必须通过指定自己的转义字符来选择加入，例如：
something LIKE '100=%' ESCAPE '='
为了实现跨数据库兼容性，最好始终使用
LIKE…
ESCAPE表单，并选择除可怕的反斜杠之外的其他东西！（此外-
MySQL的SQL字符串文字转义的反斜杠也不符合ANSI！但是您可以使用NO_BACKSLASH_ESCAPES sql_mode设置来消除这种不当行为。）
可能更好的主意是将其分解
services为第二个表，而不是将它们压缩为单个字符串列-即。将您的架构放入第一范式。然后，您可以简单地查找各个值，而不必执行慢的全表扫描子字符串匹配。
