¿Es una vista más rápida que una simple consulta?

Es un

select *  from myView

más rápido que la consulta en sí para crear la vista (para tener el mismo conjunto de resultados):

select * from ([query to create same resultSet as myView])

?

No me resulta totalmente claro si la vista utiliza algún tipo de almacenamiento en caché, lo que la hace más rápida en comparación con una consulta simple.

Sí , las vistas pueden tener un índice agrupado asignado y, cuando lo hacen, almacenan resultados temporales que pueden acelerar las consultas resultantes.

Actualización: al menos tres personas me han votado en contra de este. Con el debido respeto, creo que simplemente están equivocados; La propia documentación de Microsoft deja muy claro que las Vistas pueden mejorar el rendimiento.

Primero, las vistas simples se expanden en su lugar y, por lo tanto, no contribuyen directamente a las mejoras de 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 que se crea un índice agrupado único en la vista, el conjunto de resultados de la vista se materializa inmediatamente y persiste en el almacenamiento físico en la base de datos, ahorrando la sobrecarga de realizar esta operación costosa en el momento de la ejecución.

En segundo lugar, estas vistas indexadas pueden funcionar incluso cuando otra consulta no las haga referencia directamente, ya que el optimizador las usará en lugar de una referencia de tabla cuando sea apropiado.

De nuevo, la documentación:

La vista indizada se puede utilizar en una ejecución de 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 puede ser sustituida por una parte o la totalidad de la consulta en el plan de consulta de menor costo. En el segundo caso, se usa la vista indizada en lugar de las tablas subyacentes y sus índices ordinarios. No es necesario hacer referencia a la vista en la consulta para que el optimizador de consultas la use 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 cuadros 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 refutado.

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 pocos años, tenemos más de 1,000,000 de registros. Sin embargo, a menudo necesitamos informar las ventas a efectos fiscales y descubrimos que solo hemos vendido 100 copias de nuestro software en nuestro país de origen. Al crear una vista indexada de solo los registros lituanos, podemos mantener los registros que necesitamos en un caché indexado como se describe en la documentación de MS. Cuando ejecutamos nuestros informes de ventas lituanas en 2008, nuestra consulta buscará en un índice con una profundidad de solo 7 (Log2 (100) con algunas hojas no utilizadas). Si hiciéramos lo mismo sin la VISTA y solo 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í misma nos proporcionaría una ventaja de rendimiento (3x) sobre el simple uso del índice solo. Intenté usar un ejemplo del mundo real, pero notarás que una simple lista de ventas lituanas nos daría una ventaja aún mayor.

Tenga en cuenta que solo estoy usando un árbol b recto para mi ejemplo. Si bien estoy bastante seguro de que SQL Server utiliza alguna variante de un árbol b, no conozco los detalles. No obstante, el punto es válido.

Actualización 3: surgió la pregunta sobre si una Vista indexada solo usa un índice colocado en la tabla subyacente. Es decir, parafraseando: "una vista indizada es el equivalente de un índice estándar y no ofrece nada nuevo o exclusivo de 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 indizadas proporcionan beneficios de rendimiento adicionales que no se pueden lograr con í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 en caché que utiliza un índice definido en la tabla principal. Por lo tanto, sigo apoyando esta respuesta.

En general, no. Las vistas se utilizan principalmente para mayor comodidad y seguridad, y no producirán (por sí mismas) ningún beneficio de velocidad.

Dicho esto, SQL Server 2000 y superior tienen una característica llamada Vistas indexadas que puede mejorar enormemente el rendimiento, con algunas advertencias:

1. No todas las vistas se pueden convertir en una vista indizada; que tienen que seguir un conjunto específico de directrices , que (entre otras restricciones) significa que no puede incluir elementos de preguntas comunes como COUNT, MIN, MAX, o TOP.
2. Las vistas indizadas usan espacio físico en la base de datos, al igual que los índices en una tabla.

Este artículo describe los beneficios y limitaciones adicionales de las vistas indexadas :

Usted puede…

• 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 contra la vista.
• Puede actualizar los datos en las tablas subyacentes, incluidas las inserciones, actualizaciones, eliminaciones e incluso truncamientos.

No puedes ...

• La definición de vista no puede hacer referencia a otras vistas o tablas en otras bases de datos.
• No puede contener COUNT, MIN, MAX, TOP, combinaciones externas o algunas otras palabras clave o elementos.
• No puede modificar las tablas y columnas subyacentes. La vista se crea con la opción WITH SCHEMABINDING.
• No siempre se puede predecir qué hará el optimizador de consultas. Si utiliza Enterprise Edition, considerará automáticamente el índice agrupado único como una opción para una consulta, pero si encuentra un índice "mejor", se utilizará. Puede forzar al optimizador a usar el índice a través de la sugerencia WITH NOEXPAND, pero tenga cuidado al usar 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 normales, según los parámetros de consulta / vista. Para ambos, se eliminan de la memoria caché cuando no se han utilizado durante un período suficientemente largo 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á reutilizando la misma consulta SQL y la misma vista con la misma frecuencia.

Obviamente, en general, una vista, por su propia naturaleza (que alguien pensara que debía usarse con la frecuencia suficiente para convertirla en una vista), es más probable que sea "reutilizada" que cualquier declaración SQL arbitraria.

EDITAR: Estaba equivocado, y deberías ver la respuesta de Marks arriba.

No puedo hablar por experiencia con SQL Server , pero para la mayoría de las bases de datos la respuesta sería no. El único beneficio potencial que obtiene, en términos de rendimiento, al usar una vista es que potencialmente podría crear algunas rutas de acceso basadas en la consulta. Pero la razón principal para usar una vista es simplificar una consulta o estandarizar una forma de acceder a algunos datos en una tabla. En términos generales, no obtendrá un beneficio de rendimiento. Yo podría, sin embargo, estar equivocado.

Se me ocurriría un ejemplo moderadamente más complicado y lo cronometraría usted mismo para verlo.

Puede ser más rápido si crea una vista materializada ( con enlace de esquema ). Las vistas no materializadas se ejecutan como la consulta normal.

Tengo entendido que hace un tiempo, una vista sería más rápida porque SQL Server podría almacenar un plan de ejecución y luego simplemente usarlo en lugar de tratar de resolver uno sobre la marcha. Creo que el aumento de rendimiento en la actualidad probablemente no sea tan bueno como lo era antes, pero tendría que adivinar que habría una mejora marginal para usar la vista.

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), había realizado algunas pruebas y experimentado 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 vista de la consulta se completó en la mitad del tiempo. Yo diría que eso es prueba suficiente para mí.

Esperaría que las dos consultas se realicen de manera idéntica. Una vista no es más que una definición de consulta almacenada, no hay almacenamiento en caché o almacenamiento de datos para una vista. El optimizador convertirá efectivamente su primera consulta en su segunda consulta cuando la ejecute.

Todo depende de la situación. Las vistas indizadas de MS SQL son más rápidas que una vista o consulta normal, pero las vistas indizadas no se pueden usar en un entorno de base de datos reflejado (MS SQL).

Una vista en cualquier tipo de bucle causará una desaceleración grave porque la vista se repobla cada vez que se llama en el bucle. Lo mismo que una consulta. En esta situación, una tabla temporal que usa # o @ para mantener sus datos en bucle es más rápida que una vista o una consulta.

Entonces todo depende de la situación.

No existe una diferencia práctica y si lee BOL, descubrirá que su antiguo SQL SELECT * FROM X aprovecha el plan de almacenamiento en caché, etc.

Debería haber alguna ganancia trivial al tener el plan de ejecución almacenado, pero será insignificante.

El propósito de una vista es usar la consulta una y otra vez. Con ese fin, SQL Server, Oracle, etc. proporcionarán típicamente una versión "en caché" o "compilada" de su vista, mejorando así su rendimiento. En general, esto debería funcionar mejor que una consulta "simple", aunque si la consulta es realmente muy simple, los beneficios pueden ser insignificantes.

Ahora, si está haciendo una consulta compleja, cree la vista.

En mi opinión, usar la vista es un poco más rápido que una consulta normal. Mi procedimiento almacenado estaba tomando alrededor de 25 minutos (trabajando con diferentes conjuntos de registros más grandes y múltiples combinaciones) y después de usar la vista (no agrupada), el rendimiento fue un poco más rápido pero no significativo en absoluto. Tuve que usar algunas otras técnicas / métodos de optimización de consultas para hacer un cambio dramático.

Seleccionar desde una Vista o desde una tabla no tendrá demasiado sentido.

Por supuesto, si la Vista no tiene uniones, campos, etc. innecesarios. Puede verificar el plan de ejecución de sus consultas, uniones e índices utilizados para mejorar el rendimiento de la Vista.

Incluso puede crear índices de vistas para requisitos de búsqueda más rápidos. http://technet.microsoft.com/en-us/library/cc917715.aspx

Pero si está buscando como '% ...%', el motor sql no se beneficiará de un índice en la columna de texto. Si puede obligar a sus usuarios a realizar búsquedas como '...%', eso será rápido

referido a la respuesta en los foros de asp: https://forums.asp.net/t/1697933.aspx?Which+is+faster+when+using+SELECT+query+VIEW+or+Table+

Contra todo pronóstico, las opiniones son mucho más lentas en algunas circunstancias.

Descubrí esto recientemente cuando tuve problemas con los datos que fueron extraídos de Oracle y que necesitaban un masaje en otro formato. Tal vez 20k filas de origen. Una pequeña mesa. Para hacer esto, importamos los datos de Oracle lo más inalterados que pude en una tabla y luego usamos vistas para extraer datos. Teníamos vistas secundarias basadas en esas vistas. Tal vez 3-4 niveles de vistas.

¡Una de las consultas finales, que extrajo unas 200 filas, tomaría más de 45 minutos! Esa consulta se basó en una cascada de vistas. Tal vez 3-4 niveles de profundidad.

Podría tomar cada una de las vistas en cuestión, insertar su sql en una consulta anidada y ejecutarla en un par de segundos.

Incluso descubrimos que incluso podíamos escribir cada vista en una tabla temporal y consultar eso en lugar de la vista y aún así era mucho más rápido que simplemente usar vistas anidadas.

Lo que fue aún más extraño fue que el rendimiento estuvo bien hasta que alcanzamos un límite de filas de origen que se introdujeron en la base de datos, el rendimiento se dejó caer por un acantilado en el espacio de un par de días; unas pocas filas de origen más fueron todo lo que tomó.

Entonces, el uso de consultas que extraen de las vistas que extraen de las vistas es mucho más lento que una consulta anidada, lo que no tiene sentido para mí.

Me encontré con este hilo y solo quería compartir esta publicación de Brent Ozar como algo a tener en cuenta al usar grupos de disponibilidad.

Informe de error de Brent Ozar