Eficiencia de T/SQL y orden de ejecución

Question

Con respecto al orden de ejecución de las sentencias en SQL, ¿hay alguna diferencia entre las siguientes en cuanto a rendimiento?

SELECT * FROM Persons 
WHERE UserType = 'Manager' AND LastName IN ('Hansen','Pettersen') 

Y:

SELECT * FROM Persons 
WHERE LastName IN ('Hansen','Pettersen') AND UserType = 'Manager' 

Si hay alguna diferencia, es que hay tal vez un enlace, etc., que es posible que tenga donde uno puede aprender más acerca de esto?

Gracias por tonelada,

Kyle

Answer 1

El optimizador, dado que utiliza un optimizador basado en el costo, decidirá qué "ruta" es la mejor: le costará las opciones según las estadísticas y luego irá desde allí. El orden de los términos no debe hacer ninguna diferencia (aunque la forma en que anides las cosas, puede hacer una diferencia).

EDITAR: Oracle solía tener hasta hace poco tiempo un optimizador basado en reglas (RBO), pero que has now been phased out. Como el RBO no funcionaba con las estadísticas, era posible ver diferencias en los planes de consulta en función del orden de los predicados.

Answer 2

En todas las principales bases de datos SQL, no hay diferencia.

Answer 3

No hay diferencia en absoluto. Ambos darán como resultado el mismo plan de ejecución.

Answer 4

No habrá diferencia. Puede subir la consulta en SQL Server y hacer clic en el icono Mostrar plan de ejecución estimado y verificar el plan de ejecución para las dos consultas. Deben ser idénticos.

Answer 5

El optimizador es libre de reordenar y ejecutar predicados, ya que encuentra que la mayoría de los son eficientes/rentables para recuperar los datos.

Does the order of criteria the WHERE clause matter?

Answer 6

voy a añadir la siguiente link.

El plan de consulta se selecciona según las estadísticas de la tabla y los índices implicados (teniendo en cuenta las operaciones que deben realizarse). Si el plan de ejecución de consultas elegido es el mejor depende de muchos factores, pero la respuesta a su pregunta es que MS SQL producirá el mismo plan independientemente (considerará el mejor orden para las tres condiciones y encontrará el mismo resultado al final)

Sin embargo, debe tenerse en cuenta que los planificadores no son perfectos y solo estiman el costo, por lo que en algunos casos (siempre que conozca las limitaciones de su planificador de consultas) puede reescribir las condiciones de consulta para ayudar el planificador ve un mejor camino.

Esto (si es posible) se debe intentar solo para las consultas que se demuestre que son cruciales y también tenga en cuenta que este tipo de optimización puede ralentizar las cosas cuando cambian las estadísticas de datos.

Además, en la mayoría de los casos, existen formas mejores (cambiar índices) para optimizar consultas, y esto debe dejarse en manos del planificador de consultas.

Uno de los puntos principales de RDBMS fue no para especificar cómo recuperar datos (naturaleza declarativa de las consultas) - y en la mayoría de los casos, los planificadores de consultas de hoy encontrarán un buen plan para usted.

Answer 7

En SQL Server 2000 hay una diferencia. Tuve muchos dolores de cabeza con este. Aparentemente evalúa las cláusulas where en el orden en que se definen. Para especificar si quería que los datos se filtraran a través de un índice, tuve que agregar la cláusula WITH (INDEX (MY_INDEX_NAME1, MY_INDEX_NAME2)) después de la declaración FROM.