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
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. –
Może to mieć coś wspólnego z zestawem znaków bazy danych. Zaktualizowałem oryginalny wpis. – EnToutCas
Zaznacz to: - 'wybierz @@ session.sql_mode; select @@ global.sql_mode; ' – ajreal