¿Es una vista más rápida que una simple consulta?
Es un
select * from myView
más rápido que la consulta misma para crear la vista (para tener el mismo conjunto de resultados):
select * from ([query to create same resultSet as myView])
?
No me queda del todo claro si la vista utiliza algún tipo de almacenamiento en caché que la haga más rápida en comparación con una consulta simple.
Sí , las vistas pueden tener asignado un índice agrupado y, cuando lo tengan, almacenarán resultados temporales que pueden acelerar las consultas resultantes.
La propia documentación de Microsoft deja muy claro que las Vistas pueden mejorar el rendimiento.
En primer lugar, la mayoría de las vistas que crean las personas son vistas simples y no utilizan esta característica y, por lo tanto, no son diferentes de consultar las tablas base directamente. Las vistas simples se amplían en el lugar y, por lo tanto, no contribuyen directamente a las mejoras del rendimiento ; eso es cierto. Sin embargo, las vistas indexadas pueden mejorar drásticamente el rendimiento.
Déjame ir directamente a la documentación:
Después de crear un índice agrupado único en la vista, el conjunto de resultados de la vista se materializa inmediatamente y persiste en el almacenamiento físico de la base de datos, lo que ahorra la sobrecarga de realizar esta costosa operación en el momento de la ejecución.
En segundo lugar, estas vistas indexadas pueden funcionar incluso cuando otra consulta no hace referencia directa a ellas, ya que el optimizador las usará en lugar de una referencia de tabla cuando sea apropiado.
De nuevo, la documentación:
La vista indexada se puede utilizar en la ejecución de una consulta de dos maneras. La consulta puede hacer referencia a la vista indexada directamente o, lo que es más importante, el optimizador de consultas puede seleccionar la vista si determina que la vista se puede sustituir por parte o la totalidad de la consulta en el plan de consulta de menor costo. En el segundo caso, se utiliza la vista indexada en lugar de las tablas subyacentes y sus índices habituales. No es necesario hacer referencia a la vista en la consulta para que el optimizador de consultas la utilice durante la ejecución de la consulta. Esto permite que las aplicaciones existentes se beneficien de las vistas indexadas recién creadas sin cambiar esas aplicaciones.
Esta documentación, así como los gráficos que demuestran las mejoras de rendimiento, se pueden encontrar aquí .
Actualización 2: la respuesta ha sido criticada porque es el "índice" el que proporciona la ventaja de rendimiento, no la "Vista". Sin embargo, esto es fácilmente refutable.
Digamos que somos una empresa de software en un país pequeño; Usaré Lituania como ejemplo. Vendemos software en todo el mundo y mantenemos nuestros registros en una base de datos de SQL Server. Tenemos mucho éxito y, en unos pocos años, tenemos más de 1.000.000 de registros. Sin embargo, a menudo necesitamos declarar las ventas a efectos fiscales y descubrimos que sólo hemos vendido 100 copias de nuestro software en nuestro país de origen. Al crear una vista indexada solo de los registros lituanos, podemos mantener los registros que necesitamos en una caché indexada como se describe en la documentación de MS. Cuando ejecutamos nuestros informes de ventas en Lituania en 2008, nuestra consulta buscará en un índice con una profundidad de sólo 7 (Log2(100) con algunas hojas sin usar). Si tuviéramos que hacer lo mismo sin la VISTA y simplemente confiando en un índice en la tabla, ¡tendríamos que atravesar un árbol de índice con una profundidad de búsqueda de 21!
Claramente, la Vista en sí nos proporcionaría una ventaja de rendimiento (3 veces) sobre el simple uso del índice por sí solo. Intenté utilizar un ejemplo del mundo real, pero notará que una lista simple de las ventas en Lituania nos daría una ventaja aún mayor.
Tenga en cuenta que solo estoy usando un árbol b directo para mi ejemplo. Si bien estoy bastante seguro de que SQL Server utiliza alguna variante de un árbol b, no conozco los detalles. Sin embargo, el punto se mantiene.
Actualización 3: ha surgido la pregunta sobre si una vista indexada solo utiliza un índice colocado en la tabla subyacente. Es decir, parafraseando: "una vista indexada es simplemente el equivalente de un índice estándar y no ofrece nada nuevo o exclusivo para una vista". Si esto fuera cierto, por supuesto, entonces el análisis anterior sería incorrecto. Permítanme proporcionar una cita de la documentación de Microsoft que demuestra por qué creo que esta crítica no es válida o verdadera:
El uso de índices para mejorar el rendimiento de las consultas no es un concepto nuevo; sin embargo, las vistas indexadas brindan beneficios de rendimiento adicionales que no se pueden lograr utilizando índices estándar.
Junto con la cita anterior sobre la persistencia de los datos en el almacenamiento físico y otra información en la documentación sobre cómo se crean los índices en las Vistas, creo que es seguro decir que una Vista indexada no es solo una Selección SQL almacenada en caché que utiliza un índice definido en la tabla principal. Por lo tanto, sigo defendiendo esta respuesta.
En términos generales, no. Las vistas se utilizan principalmente por conveniencia y seguridad, y (por sí solas) no producirán ningún beneficio de velocidad.
Dicho esto, SQL Server 2000 y superiores tienen una característica llamada Vistas indexadas que puede mejorar enormemente el rendimiento, con algunas advertencias:
- No todas las vistas se pueden convertir en vistas indexadas; deben seguir un conjunto específico de pautas , lo que (entre otras restricciones) significa que no se pueden incluir elementos de consulta comunes como
COUNT,MIN,MAXoTOP. - Las vistas indexadas utilizan espacio físico en la base de datos, al igual que los índices en una tabla.
Este artículo describe beneficios y limitaciones adicionales de las vistas indexadas :
Puedes…
- La definición de vista puede hacer referencia a una o más tablas en la misma base de datos.
- Una vez que se crea el índice agrupado único, se pueden crear índices no agrupados adicionales en la vista.
- Puede actualizar los datos en las tablas subyacentes, incluidas inserciones, actualizaciones, eliminaciones e incluso truncamientos.
No puedes…
- La definición de vista no puede hacer referencia a otras vistas ni a tablas de otras bases de datos.
- No puede contener COUNT, MIN, MAX, TOP, combinaciones externas ni algunas otras palabras clave o elementos.
- No puede modificar las tablas y columnas subyacentes. La vista se crea con la opción CON SCHEMABINDING.
- No siempre se puede predecir lo que hará el optimizador de consultas. Si está utilizando Enterprise Edition, considerará automáticamente el índice agrupado único como una opción para una consulta, pero si encuentra un índice "mejor", lo utilizará. Puede obligar al optimizador a utilizar el índice mediante la sugerencia CON NOEXPAND, pero tenga cuidado al utilizar cualquier sugerencia.
Al menos en SQL Server, los planes de consulta se almacenan en la memoria caché del plan tanto para las vistas como para las consultas SQL ordinarias, en función de los parámetros de consulta/vista. Para ambos, se eliminan de la caché cuando no se han utilizado durante un período de tiempo suficiente y se necesita espacio para alguna otra consulta recién enviada. Después de lo cual, si se emite la misma consulta, se vuelve a compilar y el plan se vuelve a colocar en la memoria caché. Entonces no, no hay diferencia, dado que estás reutilizando la misma consulta SQL y la misma vista con la misma frecuencia.
Obviamente, en general, una vista, por su propia naturaleza (que alguien pensó que debía usarse con la frecuencia suficiente para convertirla en una vista) generalmente tiene más probabilidades de ser "reutilizada" que cualquier declaración SQL arbitraria.
Definitivamente una vista es mejor que una consulta anidada para SQL Server. Sin saber exactamente por qué es mejor (hasta que leí la publicación de Mark Brittingham), realicé algunas pruebas y experimenté mejoras de rendimiento casi impactantes al usar una vista versus una consulta anidada. Después de ejecutar cada versión de la consulta varios cientos de veces seguidas, la versión de visualización de la consulta se completó en la mitad del tiempo. Yo diría que eso es prueba suficiente para mí.
Jan 13 '2009 16:01
Puede ser más rápido si crea una vista materializada ( con enlace de esquema ). Las vistas no materializadas se ejecutan igual que la consulta normal.
