¿Las vistas de la base de datos afectan el rendimiento de la consulta?

Question

¿Las vistas de la base de datos son solo un medio para simplificar el acceso a los datos o proporcionan beneficios de rendimiento al acceder a las vistas en lugar de solo ejecutar la consulta en la que se basa la vista? Sospecho que las vistas son funcionalmente equivalentes a solo agregar la consulta de vista almacenada a cada consulta en los datos de vista, ¿es correcto o hay otros detalles y/o optimizaciones que suceden?

Answer 1

Depende del RDBMS, pero generalmente no hay optimización, y es solo una forma conveniente de simplificar las consultas. Algunos sistemas de bases de datos usan "vistas materializadas", sin embargo, que usan un mecanismo de almacenamiento en caché.

Answer 2

Por lo general, una vista es solo una forma de crear una abreviatura común para definir los conjuntos de resultados que necesita con frecuencia.

Sin embargo, hay un inconveniente. La tentación es agregar en cada columna que crees que necesitarás en algún momento cuando desees utilizar la vista. Entonces YAGNI es violado. No solo las columnas, sino que a veces se unen las uniones externas adicionales en "por las dudas". Así que cubrir los índices puede que ya no cubran, y el plan de consulta puede aumentar en complejidad (y disminuir la eficiencia).

YAGNI es un concepto crítico en el diseño SQL.

Answer 3

Siempre he considerado las Vistas como procedimientos almacenados de solo lectura. Proporciona a la base de datos la mayor cantidad de información posible por adelantado para que pueda precompilar lo mejor que pueda.

También puede indexar las vistas, lo que le permite acceder a una vista optimizada de los datos que está buscando para el tipo de consulta que está ejecutando.

Answer 4

En general, las vistas deben realizarse de manera equivalente a una consulta escrita directamente en las tablas subyacentes.

Pero: puede haber casos de bordes, y le conviene probar su código. Todos los sistemas RDBMS modernos tienen herramientas que le permitirán ver los planes de consulta y supervisar la ejecución. No tome mi palabra (ni la de nadie) por ella, cuando pueda tener los datos definitivos a su alcance.

Answer 5

Aunque una consulta determinada que se ejecuta dentro de una vista y la misma consulta que se ejecuta fuera de la vista deben funcionar de manera equivalente, las cosas se vuelven mucho más complicadas rápidamente cuando necesita unir dos vistas. Puede terminar fácilmente trayendo tablas que no necesita en la consulta, o trayendo tablas de forma redundante. El optimizador de la base de datos puede tener más problemas para crear un buen plan de ejecución de consultas. Por lo tanto, aunque las vistas pueden ser muy buenas en términos de permitir una seguridad de grano más fino y similares, no son necesariamente buenas para la modularidad.

Answer 6

Sé que este es un hilo viejo. La discusión es buena, pero quiero echar un pensamiento más. El rendimiento también depende de lo que está utilizando para extraer datos. Por ejemplo, si tiene acceso directo a algo como Microsoft Access, definitivamente puede obtener rendimiento para algunas consultas complejas mediante el uso de una vista. Esto se debe a que Access no siempre extrae del servidor SQL lo que quisiéramos, en algunos casos atraería tablas enteras e intentaría procesar localmente desde allí. No es así si usa una vista.

Answer 7

Sí, en todos los RDBMS modernos (MSSQL después de 2005? Etc.) los planes de consulta de la vista se almacenan en caché eliminando la sobrecarga de la planificación de la consulta y acelerando el rendimiento en el mismo SQL ejecutado en línea. Anteriormente a esto (y también se aplica a SQL parametrizado/Declaraciones preparadas), las personas pensaban correctamente que los procedimientos almacenados tenían un mejor rendimiento.

Muchos todavía se aferran a esto hoy por lo que es un mito DB moderno. Desde que Views/PS obtuvieron la planificación de consulta en caché de los SP, han sido bastante parejos.