MySQL - Y condición

Question

Digamos que tengo una consulta como esta:

SELECT bla WHERE foo LIKE '%bar%' AND boo = 'bar' AND whatvr IN ('foo', 'bar')... 

Me preguntaba si MySQL sigue comprobando todas las condiciones cuando se recuperan los resultados. Por ej. si foo no es LIKE %bar%, ¿continuará verificando boo = 'bar', y así sucesivamente?

¿Sería más rápido si pongo condiciones que es menos probable que sean ciertas al final?

Lo siento si esto parece ser pregunta estúpida, soy un completo noob cuando se trata de SQL :)

Answer 1

No creo que haya garantías acerca de si o no múltiples condiciones serán cortocircuito, pero ...

En general, debe tratar el optimizador de consultas como una caja negra y asumir, a menos que tenga pruebas en contrario, que hará su trabajo correctamente. El trabajo del optimizador es garantizar que los datos solicitados se recuperen de la manera más eficiente posible. Si el plan más eficiente implica un cortocircuito, entonces lo hará; si no lo hace, entonces no lo hará.

(Por supuesto, los optimizadores de consultas no son perfectos. Si tiene evidencia de que una consulta no se ejecuta de manera óptima, a menudo vale la pena volver a ordenarla y/o volver a formularla para ver si algo cambia).

Answer 2

No puede confiar en las condiciones de evaluación de MySQL de izquierda a derecha (a diferencia de cualquier lenguaje de programación). Esto se debe a que el "optimizador de cláusula WHERE" busca columnas que están indexadas y buscará primero este subconjunto.

Para la optimización de consultas, consulte el capítulo Optimizing SELECT Statements en el manual de referencia de MySQL.

Answer 3

Lo que está buscando es documentación sobre la evaluación de cortocircuito de MySQL. Sin embargo, no he podido encontrar nada mejor que las personas que fueron no capaces de encontrar la documentación, pero claim lo han probado y lo encontraron verdadero, es decir, cortocircuitos MySQL.

¿Sería más rápido si pongo condiciones que es menos probable que sean ciertas al final?

No, el optimizador intentará y optimizará (!) El orden de procesamiento. Por lo tanto, en cuanto al pedido de pruebas, debe no asumir nada.

Answer 4

No me gustaría contar con eso: Where Optimisations. Ese enlace explica que prevalecen otros criterios en la orden.

Answer 5

Si se produce un cortocircuito cuando la primera condición falla (lo que es más probable), lo mejor sería poner esas condiciones, que es más probable que fallen, ¡primero!

digamos que tenemos 3 condiciones, y todas deben ser verdaderas (separadas por "Y"). caja lenta: 1. nunca falle. Todas las filas son revisadas y exitosas. 2. a veces fallan. Todas las filas son revisadas y aún exitosas. 3. a menudo fallan. Todas las filas son revisadas y esta vez fallamos. Resultado: llevó un tiempo, pero no se puede encontrar una coincidencia.

caja rápida: 1. a menudo fallan. Todas las filas se revisan y las coincidencias fallan. 2. a veces fallan. NO mirado, porque la búsqueda terminó debido a un cortocircuito. 3. nunca falle. NO mirado, porque la búsqueda terminó debido a un cortocircuito. Resultado: figurado rápidamente, no coincide.

Corrígeme si me equivoco. Me imagino que todas las condiciones están marcadas, para cada fila se veía anuncios. Lo cual hace que esto importe MUCHO menos. Si sus campos están ordenados en el mismo orden, como sus condiciones, quizás pueda medir la diferencia.