Está frustrado con el escape de patrón de MySQL usado en el operador LIKE.Operador de MySQL LIKE con comodín y barra diagonal inversa
[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)
De acuerdo con documentos de MySQL: http://dev.mysql.com/doc/refman/5.5/en/string-comparison-functions.html#operator_like %\\\\%
es el operando de la derecha, pero ¿por qué no da resultado?
EDITAR: La base de datos que estoy probando en tiene character_set_database establecido en utf8. Para ampliar mi investigación, creé la misma configuración en una base de datos que tiene character_set_database establecida en latin1, y adivinen qué, '%\\\\%'
funciona.
EDITAR: El problema se puede reproducir y es el problema de intercalación de campo. Detalles: http://bugs.mysql.com/bug.php?id=63829
Cuando uso sus comandos exactamente, 'select * from foo donde name like '% \\\\%';' funciona para mí. Aunque no entiendo por qué no funciona para ti, tengo curiosidad por saberlo. –
Puede tener algo que ver con el juego de caracteres de la base de datos. Actualicé la publicación original. – EnToutCas
Compruebe esto: - 'select @@ session.sql_mode; select @@ global.sql_mode; ' – ajreal