SQL 'LIKE BINARY' más lento que simple 'LIKE'?

Question

Estoy usando una aplicación django que realiza algunas operaciones ORM 'startswith' comparando columnas longtext con una cadena Unicode. Esto da como resultado una operación de comparación LIKE BINARY con una cadena unicode u'mystring'. ¿Es probable que LIKE BINARY sea más lento que un LIKE simple?

Sé que la respuesta general es la evaluación comparativa, pero me gustaría obtener una idea general para las bases de datos en general en lugar de solo mi aplicación ya que nunca antes había visto una consulta LIKE BINARY.

Yo uso MySQL pero me interesa la respuesta para bases de datos SQL en general.

Answer 1

Si el rendimiento parece convertirse en un problema, podría ser una buena idea para crear una copia de la primera, por ejemplo. 255 caracteres del texto largo, agregue un índice sobre eso y use el startswith con eso.

Por cierto, this page says: ". Si lo que necesita hacer juego entre mayúsculas y minúsculas, declare su columna como binarios, no use COMO binario en sus consultas para emitir una columna no binario Si lo hace, no lo hará MySQL use cualquier índice en esa columna ". Es un viejo consejo, pero creo que esto sigue siendo válido.

Answer 2

Para la próxima persona que corre a través de esto - en nuestra relativamente pequeña base de datos de la consulta:

SELECT * FROM table_name WHERE field LIKE 'some-field-search-value'; 

... Result row 

Returns 1 row in set (0.00 sec) 

En comparación con:

SELECT * FROM table_name WHERE field LIKE BINARY 'some-field-search-value'; 

... Result row 

Returns 1 row in set (0.32 sec) 

larga historia corta, al menos por nuestra base de datos (MySQL 5.5/InnoDB) hay una diferencia muy significativa en el rendimiento entre las dos búsquedas.

Al parecer, aunque esto es un error en MySQL 5.5: http://bugs.mysql.com/bug.php?id=63563 y en mis pruebas en contra de la misma base de datos en MySQL 5.1 la consulta BINARIO COMO sigue utilizando el índice (mientras que en 5.5 se realiza un escaneo completo de tabla.)