Es importante reconocer que SQL es un lenguaje declarativo. La SELECT
consulta 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 WHERE
predicados 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