Optimización de SQL y forma normal disyuntiva

Estaba escribiendo una consulta en Visual Studio 2010 (me refiero a que abrí el explorador del servidor, hice clic con el botón derecho en el servidor y seleccioné Nueva consulta). La consulta incluye la condiciónOptimización de SQL y forma normal disyuntiva

A AND B AND C AND D AND E AND F AND (G OR H)

que es la forma normal conjuntiva (CNF). Cuando me encontré con la consulta (que se adjunta a MSSQL Server 2008), cambió el texto en

A AND B AND C AND D AND E AND F AND G OR 
A AND B AND C AND D AND E AND F AND H

que es la forma normal disyuntiva (DNF).

Por lo poco que encontré en línea, parece que DNF permite que SQL ejecute los conjuntivos por separado y los una al final.

Sin embargo, para algo como esto, con tantas condiciones repetidas, ¿ofrece realmente DNF una ventaja sobre CNF? Si no es así, ¿cómo puedo forzar al optimizador a tomar la condición tal como está? Si es así, ¿debo escribir la consulta en el código de mi aplicación en formato CNF porque es más corta y ordenada o en formato DNF porque ahorra tiempo para el optimizador?

Fuente

2011-07-25 Jodaka

¿de dónde cambiar el texto de la consulta? ¿Puedes publicar una captura de pantalla? – Justin

Lamentablemente, no es una forma fácil de publicar una captura de pantalla (las computadoras en el trabajo son raras). En cuanto a la primera pregunta, estaba en una pestaña de consulta en VS2010 (donde hay cuatro paneles, Diagrama, Criterios, SQL, Resultados) y sobrescribió el SQL que había escrito con el nuevo texto. – Jodaka

Nunca busqué implementaciones concretas de motores SQL, aparte del mío. ^^ Así que no sé si la ejecución de la consulta real se acelerará a través de DNF. Lo que PUEDO decir es que DNF es al menos un enfoque interesante para el almacenamiento en caché. El motor SQL podría transformar la consulta a DNF para poder verificar si la consulta se ha ejecutado antes. Y si es así, quizás las traducciones de consulta de SQL a representaciones nativas o incluso los resultados de la consulta podrían entregarse desde el caché. Pero estoy de acuerdo con Clockwork-Muse y dejaré eso al motor SQL y escribiré una consulta legible yo mismo. – user573215

No conozco las ventajas relativas de DNF/CNF en esta situación, o incluso cómo forzar el optimizador de esta manera.

En términos generales, no desea obligar al optimizador a llevar a cabo su optimización 'percibida', 'actual', sobre la que generará (hay excepciones a esto, pero generalmente son raras). Esto tiene que ver en gran parte con el hecho de que la "mejor" optimización puede cambiar con el tiempo, como un efecto secundario de otras acciones (como agregar un índice). Si está forzando al optimizador a adoptar una optimización particular, la está bloqueando en esa ruta, incluso si una nueva funciona mejor.

Teniendo en cuenta que, usted debe escribir la consulta en la forma que sea más fácil de leer y mantener (CNF), y dejar que el cambio optimizador si es necesario - este es el punto central de SQL ser un declarativa lenguaje , a permita que el optimizador ensucie las cosas según sea necesario.

Fuente

2011-07-25 17:01:45

En la parte superior de mi cabeza, me pregunto sobre la indexación en G o H. Si G estaba indexado, pero H no era ... tal vez una disyuntiva tendría más sentido.

de todos modos, puede ejecutar usted mismo el analizador de rendimiento para ver la diferencia neta en el rendimiento.

Además de eso, he aquí algo de la investigación que podría ser capaz de obtener acceso a si quieres bucear en: Investigación en Materiales: http://ieeexplore.ieee.org/xpl/freeabs_all.jsp?arnumber=842265&abstractAccess=no&userType=inst

Fuente

2011-07-25 17:18:45 Chains

En este caso, G y H en realidad se refieren a la misma columna; G es "col like 'word1%'" y H es "col like 'word2%'", por lo que no puedo usar IN o BETWEEN. Pero me gusta la idea. – Jodaka

Optimización de SQL y forma normal disyuntiva

Respuesta

Cuestiones relacionadas