¿Una consulta WHERE realizará comprobaciones de comparaciones más simples (es decir, bit) antes de ejecutar comparaciones más arduas (es decir, varchar)?


12

Si escribo una consulta que incluye una WHEREcláusula compuesta , por ejemplo:

SELECT *
FROM MyTable
WHERE BitField = 1
    AND VarcharField = 'asdf'

y la inclusión de esa bitcomparación simplemente excluye los mismos campos que la varcharcomparación excluirá, ¿la presencia de esa bitcomparación de campo me dará una mejora en el rendimiento?

Respuestas:


22

Es importante reconocer que SQL es un lenguaje declarativo. La SELECTconsulta que escribió especifica los resultados lógicos que deben devolverse. Depende del motor de la base de datos, específicamente del optimizador de consultas, determinar una estrategia física eficiente para devolver esos resultados.

El plan de ejecución física final dependerá de las capacidades de razonamiento del optimizador, la cantidad de tiempo que está preparado para dedicar al problema, la disponibilidad de métodos de acceso adecuados (principalmente índices y vistas materializadas), información estadística representativa y la ruta de código particular La especificación de consulta lleva a través del código de optimización.

En general, si el diseño de su base de datos es relacional, proporciona buenos métodos de acceso e información estadística precisa, y la consulta está bien escrita, el optimizador normalmente encontrará una estrategia de ejecución física razonable sin que tenga que preocuparse demasiado por la forma escrita de La especificación de la consulta demasiado.

Siempre habrá casos en los que expresar el mismo requisito lógico utilizando una sintaxis diferente (pero semánticamente idéntica) afectará el plan de ejecución física, pero eso debería ser una preocupación secundaria. Nuevamente, en general, solo considere expresar la consulta de manera diferente si las características de tiempo de ejecución son inaceptables, una vez que se hayan cubierto todos los conceptos básicos mencionados anteriormente.

Sería raro en extremo que el orden escrito de WHEREpredicados de cláusula conjuntiva simple (como en la pregunta) afecte el plan de ejecución física de cualquier manera mensurable. En resumen, esto no es algo por lo que deba pasar tiempo preocupándose. Obtenga primero el diseño de la base de datos, los índices y la información estadística.

Para responder la pregunta directamente (¡eventualmente!), Agregar la condición redundante adicional podría mejorar el rendimiento, pero solo si permite el uso de un método de acceso más eficiente, por ejemplo, si solo hay un índice en (BitField, VarcharField). Si ya hubiera un índice en (VarcharField), agregaría solo gastos generales.

Como detalle de implementación, no, SQL Server no considera el costo de las comparaciones según el tipo de datos o la aparente complejidad computacional. De hecho, las operaciones escalares cuestan muy poco , pero eso lleva a un tema completamente diferente.

Preguntas relacionadas:

Operadores lógicos OR Y en condición y orden de condiciones en DONDE
SQL Server 2008 y expresiones constantes
Operadores a nivel de bits que afectan el rendimiento
Comportamiento de instrucción SQL extraño


5

Las particiones binarias (como una columna de bits) suenan como buenos candidatos para índices filtrados.

CREATE NONCLUSTERED INDEX MyTableWithBitFieldTrue
ON MyTable (VarcharField)
INCLUDE Id, <other columns you're selecting>
WHERE BitField = 1 ;
GO

Ser explícito acerca de sus optimizaciones significa que su código es más robusto frente a los cambios de otras personas, ya sea en su base de código o en SQL Server.

Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.