Descargo de responsabilidad: todo lo que aparece a continuación es solo anecdótico y se extrae directamente de mi experiencia personal. Cualquiera que se sienta dispuesto a realizar un análisis más riguroso empíricamente puede llevarlo a cabo y votar en contra si yo lo hago. También soy consciente de que SQL es un lenguaje declarativo y se supone que no debes considerar CÓMO se procesa tu código cuando lo escribes, pero, como valoro mi tiempo, lo hago.
Hay infinitas declaraciones lógicamente equivalentes, pero consideraré tres (más o menos).
Caso 1: dos comparaciones en un orden estándar (orden de evaluación fijo)
A> = MinBound Y A <= MaxBound
Caso 2: Azúcar sintáctico (el orden de evaluación no lo elige el autor)
ENTRE MinBound Y MaxBound
Caso 3: dos comparaciones en un orden educado (orden de evaluación elegido en el momento de la escritura)
A> = MinBound Y A <= MaxBound
O
A <= MaxBound Y A> = MinBound
En mi experiencia, el Caso 1 y el Caso 2 no tienen diferencias consistentes o notables en el rendimiento, ya que ignoran el conjunto de datos.
Sin embargo, el Caso 3 puede mejorar considerablemente los tiempos de ejecución. En concreto, si se trabaja con un gran conjunto de datos y pasar a tener algún conocimiento heurístico acerca de si una es más probable que sea mayor que el MaxBound o menor que el MinBound puede mejorar notablemente los tiempos de ejecución mediante el uso de la caja 3 y ordenar las comparaciones en consecuencia.
Un caso de uso que tengo es consultar un gran conjunto de datos históricos con fechas no indexadas para registros dentro de un intervalo específico. Al escribir la consulta, tendré una buena idea de si existen más datos ANTES del intervalo especificado o DESPUÉS del intervalo especificado y puedo ordenar mis comparaciones en consecuencia. He tenido tiempos de ejecución reducidos a la mitad dependiendo del tamaño del conjunto de datos, la complejidad de la consulta y la cantidad de registros filtrados por la primera comparación.