Quiero saber cuál es la diferencia entre una consulta y una vista en términos de rendimiento. Y si una vista es costosa, ¿qué otra cosa, además de una consulta, podría hacer para mejorar el rendimiento?Consulta frente a vista
Las consultas y consultas ad-hoc, en el caso simple, son casi idénticas en términos de rendimiento. Tanto es así que cuando programa con una vista, debe pensar que el texto de la definición de la vista se está cortando y pegando en su consulta principal.
HLGEM señala en su respuesta que ciertas ediciones de SQL Server le permiten "indexar" vistas; en este caso, detrás de las escenas SQL Server mantiene las mismas estructuras subyacentes a una tabla, haciendo una vista indexada y una tabla muy similar en términos de rendimiento.
En SQL Server, aunque generalmente puede anidar las vistas bastante liberalmente sin tener problemas de rendimiento, puede hacer las cosas más difíciles de comprender y depurar.
Si se refiere al rendimiento de la red, trabajar desde un caché local (como con ADO.Net DataSets) reduciría el tráfico de red, pero podría causar problemas con el bloqueo. Solo un pensamiento.
Si hacen exactamente lo mismo, una vista puede ser ligeramente más rápida en la primera ejecución, ya que el servidor de la base de datos tendrá un plan de ejecución precompilado para ella. Depende de tu servidor sin embargo.
empasis de fuerza y un poco ...
Solo para aclarar desde una perspectiva de Oracle, las vistas no tienen un plan de ejecución almacenado asociado a ellas en esa plataforma. La definición de la vista se fusiona en la consulta y la consulta completa se optimiza. –
Una vista es todavía una consulta, sólo se abstrae ciertas partes del mismo para que sus consultas se pueden simplificar (si hacen cosas similares) y para maximizar su reutilización.
Las vistas promueven la reutilización de código y pueden abstraer la complejidad de la base de datos para proporcionar un modelo de datos "empresarial" más coherente. Sin embargo, no son tan ajustables. Es posible que se encuentre en una posición en la que necesite proporcionar sugerencias de unión u otras optimizaciones de bajo nivel, y muchos DBA con los que he trabajado no quieren que se apliquen a las vistas, ya que pueden reutilizarse en muchas consultas, y la opinión es que estas los tipos de sugerencias deben emplearse lo menos posible. Me gusta usar vistas yo mismo.
En SQL Server, creo que la diferencia de rendimiento entre vistas y consultas es insignificante. Lo que recomendaría hacer para mejorar el rendimiento es crear otra tabla que contenga los resultados de la vista. Quizás pueda crear una tabla de etapas donde se guardan datos nuevos y luego se puede ejecutar un procedimiento almacenado en algún intervalo que llene la tabla de trabajo con la nueva información. Un desencadenador podría ser bueno para este propósito. Dependiendo de los requisitos de su aplicación, este diseño puede o no ser adecuado. Si está trabajando con datos casi en tiempo real, este enfoque dará lugar a problemas de concurrencia ...
Otra cosa a tener en cuenta es asegurarse de que las tablas base que está utilizando para construir su vista estén indexadas correctamente, y que la consulta en sí está optimizada. Finalmente, creo que es posible en la empresa SQL Server crear vistas indexadas aunque no las haya usado antes.
Las tablas de consulta de materialización mantenidas manualmente son generalmente difíciles y costosas (en términos de rendimiento) para mantener con precisión, incluso ignorando el costo de espacio en disco. –
Una vista es apenas más cara para la computadora que escribir la consulta a mano. Una vista puede ahorrarle al programador/usuario mucho tiempo escribiendo la misma consulta una y otra vez, y obteniendo el error, y así sucesivamente. La vista también puede ser la única forma de acceder a los datos si las vistas también se utilizan para imponer la autorización (control de acceso) en las tablas subyacentes.
Si la consulta no funciona bien, debe revisar cómo se forma la consulta y si todas las tablas tienen los índices adecuados.Si su sistema necesita estadísticas precisas para que el optimizador funcione bien, ¿ha actualizado esas estadísticas lo suficientemente recientemente?
Hace mucho tiempo, me encontré con un sistema en el que un generador de consultas había creado una consulta que enumeraba diecisiete tablas en una sola cláusula FROM, incluyendo varios LEFT OUTER JOIN de una tabla consigo. Y, de hecho, un escrutinio más detallado reveló que varias de las "tablas" eran de hecho vistas de varias mesas, y algunas de ellas también involucraban uniones externas, y estaban ellas mismas involucradas en las uniones externas de la vista. Decir "espantoso" es un eufemismo. Hubo mucha limpieza posible para mejorar el rendimiento de esa consulta, eliminando combinaciones externas innecesarias, autocombinaciones, etc. (De hecho, era anterior a la notación explícita de unión de SQL-92, lo dije hace mucho tiempo, por lo que la sintaxis de combinación externa era específica de DBMS)
Ugh, he visto esas vistas que llaman visitas antes (casi perdimos un cliente por su bajo rendimiento que me llamaron para ayudar a solucionarlo) y son brutales de mantener y horrible para el rendimiento (y sí unirse a la misma varios millones de veces muiltiple para obtener el campo que las vistas iniciales no necesitaban, ugh). Esos tipos de cosas prácticamente suspenden nuestra revisión de código ahora. – HLGEM
No puedo hablar de todas las bases de datos, pero en SQL Server no puede indexar vistas a menos que tenga una versión Enterprise. Una vista no indexada puede ser significativamente peor en términos de rendimiento que una consulta, especialmente si está escribiendo una consulta para agregar algunas condiciones. Las vistas indizadas generalmente pueden funcionar bastante bien. Una vista indizada también puede estar en contra de múltiples campos que están en diferentes tablas y que pueden mejorar el rendimiento sobre la consulta ad hoc. (Es posible que no demasiado, en la optimización del rendimiento, debe probar siempre en contra de sus circunstancias particulares.)
Un punto en contra de puntos de vista es que no permiten la selección de tiempo de ejecución de criterios donde. Muy a menudo terminas con una vista y una consulta.
Las vistas pueden ser más fáciles de mantener (sólo añadir que la nueva tabla en una unión y todo acceso a los informes financieros lo tiene disponible) pero son mucho más difíciles de ajustar el rendimiento. Esto se debe en parte a que tienden a ser más generalizados y, por lo tanto, son más lentos que sus contrapartes, que solo devuelven el mínimo necesario. Y sí, como dijo Jonathan, es muy fácil unir puntos de vista para un informe en un lío que se une a las mismas mesas grandes muchas veces más de lo necesario y es muy lento.
Dos lugares donde las vistas Shine, aunque es: Asegurarse de que las relaciones complejas siempre se describen correctamente. Esta es una razón por la cual los redactores de informes tienden a favorecerlos. Limitar el acceso a un subconjunto de registros
También existen limitaciones en el tipo de consultas que se pueden realizar para una consulta de vista o una consulta almacenada. Por ejemplo, no puede usar una instrucción if (u otro tipo de código de procedimiento, como el bucle) o, como se indicó anteriormente, no puede proporcionar valores de tiempo de ejecución para los criterios where.
Un lugar donde las vistas son a menudo mucho más lentas es cuando llaman a otras vistas. Las vistas subyacentes deben realizarse completamente en algunas bases de datos y, por lo tanto, es posible que necesite recuperar 4.459.203 registros para ver las 10 en las que finalmente está interesado. Comience a aplicar capas a esto más de una vez y puede ser muy lento, muy rápido; las vistas que llaman vistas son simplemente una mala práctica.
Excepto cuando no lo son. Tener ese problema ahora mismo. La consulta ad-hoc es de una magnitud mucho mayor que la misma consulta convertida en una Vista. Así que siempre piense dos veces. – DanMan
@DanMan, que no es realmente un comentario útil a menos que pueda explicar las circunstancias en las que este podría ser el caso. –