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


358

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.


77
No estoy seguro de una vista, pero las vistas anidadas son un infierno de rendimiento total.
Muflix

Respuestas:


679

, 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.


29
Sí, las vistas indexadas pueden mejorar drásticamente el rendimiento. Pero las vistas indexadas no son solo "vistas", y en general, la "vista" normal no son más rápidas que sus consultas asociadas.
BradC

10
@Charles - no importa si es el índice, el hecho de que un punto de vista puede aprovechar el índice y una consulta cruda no puede es suficiente
annakata

194
/ @ Marcos aplaudir de pie firme y racional argumentando éste hacia fuera
annakata

17
¡Oh, hombre, he recibido 8 votos negativos en este caso! Me sorprende que la gente votara tan rápido sin al menos tener el coraje de Charles para discutir su punto.
Mark Brittingham el

8
Dado que una tabla solo puede tener un índice clusterdee, y PUEDE crear un índice agrupado separado en una vista, (dado que los campos en el índice agrupado persisten independientemente en las páginas de índice), esto es un truco (¿trabajo-alrededor?) Que le permite obtener DOS índices agrupados en una Tabla.
Charles Bretana el

51

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.

3
totalmente en desacuerdo ... leer desde una vista permite reescribir el SQL ... y generalmente es MÁS RÁPIDO leer desde una vista (que desde un volcado de la vista).
Aaron Kempf

@AaronKempf, me encantaría ver alguna referencia al respecto, esa no ha sido mi experiencia. Cuando busco "ver SQL reescrito", todos los resultados que obtengo se refieren a Oracle, no al servidor SQL, por ejemplo, docs.oracle.com/cd/E14072_01/server.112/e10810/qrbasic.htm
BradC

Ayer estaba haciendo una evaluación comparativa, me sorprendió ... básicamente si tomo un volcado de una vista (en una tabla), cualquier consulta que ejecuto es MENOR ... porque la mayoría de las consultas pasan por la vista como mantequilla y se reescriben por el optimizador de consultas .. Al menos eso es lo que supongo. Intentaré escribir una entrada de blog sobre él pronto, la evaluación comparativa fue algo bastante fascinante. Básicamente, las vistas ayudan enormemente al rendimiento.
Aaron Kempf

@AaronKempf No estoy seguro de que sea el mismo escenario que la pregunta original (que trata sobre una consulta frente a poner esa consulta idéntica en una vista). De todos modos, no puedo ver cómo materializar una vista en una tabla la haría MÁS LENTA (eso es exactamente lo que hace una vista indexada), a menos que su nueva tabla no tenga buenos índices.
BradC

1
Puntilla; Escribí una publicación de blog realmente mala sobre cómo las vistas me están ahorrando el 99% de mi rendimiento en esta situación. Estoy planeando escribir un par de otros artículos, pero sé que necesito poner MUCHO más detalles en esto. ¿Te importaría mirar esto y decirme qué piensas de mi descripción? Sé que no tendrá más sentido (hasta que obtenga 2-3 artículos más) ... pero estoy locamente enamorado de las opiniones, ¡y lo he estado durante mucho tiempo! accessadp.com/2013/01/22/do-views-increase-performance
Aaron Kempf

14

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.


14

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.


1
Otra razón para las vistas es ayudar al control de acceso en los modelos basados ​​en roles
annakata

1
Estás equivocado acerca de las mejoras de rendimiento. No expliqué lo suficiente para convencer a algunas personas en mi comentario original, pero MS tiene documentación explícita sobre cómo usar las vistas para mejorar el rendimiento. Vea mi respuesta (ahora fuertemente rechazada) a continuación.
Mark Brittingham el

7

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.


schemabinding tiene poco que ver con el rendimiento, vincula el esquema de la vista a la tabla subyacente para que permanezca sincronizado y es un requisito previo para las vistas indexadas.
Sam Saffron el

5

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.


Esto fue lo que entendí: solía importar, ya no importa
annakata

No desde el punto de vista del rendimiento, lo hace como un medio de restricción de acceso. Pero ese sería otro tema. ;)
AnonJr

oh, claro, hay muchas buenas razones para usar vistas, ninguna para usar consultas sin procesar: P
annakata

4

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í.


Gracias Jordan ... me alegra saber que toda esta teoría funciona en el mundo real .
Mark Brittingham el

Tengo experiencia con la vista anidada (vista a la vista) y hubo un rendimiento muy malo. Cuando todas las vistas se reescribieron en subselecciones, el rendimiento fue muchas veces más rápido, por lo que quizás haya lugar para algunas pruebas serias.
Muflix

2

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.


Si la vista es un pequeño conjunto de campos y esos campos se cubren con un índice, ¿SQL Server es lo suficientemente inteligente como para usar ese índice de cobertura al completar la segunda forma de consulta?
AnthonyWJones

1

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.


0

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.


0

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


0

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.


0

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.


Cómo estamos escribiendo / diseñando la consulta es muy importante.
kta

Descubrí que el uso de CTE para limitar los datos que regresan de una tabla y luego hacer todo el trabajo / combinaciones, etc. de los CTE ha mejorado drásticamente el rendimiento en muchos casos
MattE

0

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+


0

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í.


Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.