2011-12-20 9 views
5

Jest to frustrujące z powodu wycofywania wzoru MySQL używanego w operatorze LIKE.Operator MySQL LIKE z symbolem wieloznacznym i ukośnikiem odwrotnym

[email protected]> create table foo(name varchar(255)); 
Query OK, 0 rows affected (0.02 sec) 

[email protected]> insert into foo values('with\\slash'); 
Query OK, 1 row affected (0.00 sec) 

[email protected]> insert into foo values('\\slash'); 
Query OK, 1 row affected (0.00 sec) 

[email protected]> select * from foo where name like '%\\\\%'; 
Empty set (0.01 sec) 

[email protected]> select * from foo; 
+------------+ 
| name  | 
+------------+ 
| with\slash | 
| \slash  | 
+------------+ 
2 rows in set (0.00 sec) 

[email protected]> select * from foo where name like '%\\\\%'; 
Empty set (0.00 sec) 

[email protected]> select * from foo where name like binary '%\\\\%'; 
+------------+ 
| name  | 
+------------+ 
| with\slash | 
| \slash  | 
+------------+ 
2 rows in set (0.00 sec) 

Według docs MySQL: http://dev.mysql.com/doc/refman/5.5/en/string-comparison-functions.html#operator_like %\\\\% jest prawy argument, ale dlaczego to daje żadnego rezultatu?

EDYTOWANIE: Baza danych, której testuję, ma bazę danych character_set_database ustawioną na utf8. Aby dalej badać, utworzyłem tę samą konfigurację w bazie danych, która ma zestaw danych character_set_database na latin1, i zgadnij, co działa, '%\\\\%'!

EDIT: Problem można odtworzyć i jest to problem z sortowaniem w terenie. Szczegóły: http://bugs.mysql.com/bug.php?id=63829

+0

Kiedy używam twoich poleceń dokładnie, 'wybierz * od foo, gdzie nazwa jak '% \\\\%';' działa dla mnie. Nie wiem, dlaczego to dla ciebie nie działa, jestem ciekawy. –

+0

Może to mieć coś wspólnego z zestawem znaków bazy danych. Zaktualizowałem oryginalny wpis. – EnToutCas

+0

Zaznacz to: - 'wybierz @@ session.sql_mode; select @@ global.sql_mode; ' – ajreal

Odpowiedz

0

Wydaje się, że ma jakiś związek z tym błędem MySQL: http://bugs.mysql.com/bug.php?id=46659

myślę podłączyć do MySQL nie określając poprawną --character-set-server opcja (domyślnie latin1 z zestawień latin1_swedish_ci) io utf-8 jak prąd zestaw znaków konsoli. Powoduje to niepoprawne konwersje znaków i porównania w przypadku danych, które mają zostać przekonwertowane na kod utf8 z zestawu znaków --character-set-server.

2

W MySQL 5.6.10, z sortowania pola tekstowego utf8mb4_unicode_520_ci ten może zostać osiągnięty za pomocą 5 ukośnikowe znaków zamiast 4, a mianowicie:

select * from foo where name like binary '%\\\\\%'; 

Jakoś, wbrew wszelkim oczekiwaniom, to właściwie wyszukuje wszystkie wiersze z backslashes. Przynajmniej to powinno zadziałać, dopóki nie zostanie naprawiony błąd sortowania pola MySQL powyżej. Biorąc pod uwagę, że od wykrycia błędu minęło ponad 5 lat, każda zaprojektowana z nim aplikacja może przestać działać, zanim MySQL zostanie naprawiony - więc powinno to być całkiem niezawodny sposób obejścia tego problemu.

0

z MySQL 5.0.12 dev w systemie Windows 10 Mam następujące wyniki, kiedy zmienił zapytania z

SELECT * FROM `foo` WHERE `name` LIKE '%http:\/\/%' 

do

SELECT * FROM `foo` WHERE `name` LIKE '%http:\\\\\\\%' 

to działa i jeszcze pierwszy ciąg z ukośniki terminowy oryginalna treść pola. Wydaje się, że zinterpretował ukośne ukośniki jako ukośniki odwrotne.