El rendimiento de vistas MySql

Si va por el camino de usar vistas, ¿cómo puede garantizar un buen rendimiento?

¿O es mejor no usar vistas en primer lugar y solo incorporar el equivalente en sus declaraciones seleccionadas?

    Depende.

    Depende totalmente de lo que está viendo a través de la vista. Pero lo más probable es que reduzcas tu esfuerzo y obtengas un mayor rendimiento. Cuando la statement de SQL hace referencia a una vista no indexada, el analizador y el optimizador de consultas analizan el origen de la statement de SQL y de la vista y luego los resuelven en un solo plan de ejecución. No hay un plan para la statement SQL y un plan separado para la vista.

    Una vista no está comstackda . Es una tabla virtual compuesta de otras tablas. Cuando lo creas, no reside en algún lugar de tu servidor. Las consultas subyacentes que componen la vista están sujetas a las mismas mejoras de rendimiento o dings del optimizador de consultas. Nunca he probado el rendimiento en una vista VS su consulta subyacente, pero me imagino que el rendimiento puede variar ligeramente. Puede obtener un mejor rendimiento en una vista indizada si los datos son relativamente estáticos. Esto puede ser lo que estás pensando, tal vez en términos de “comstackdo”.

    Ventajas de vistas:

    1. Ver los datos sin almacenar los datos en el objeto.
    2. Restique la vista de una tabla, es decir, puede ocultar algunas de las columnas en las tablas.
    3. Unir dos o más tablas y mostrarlo como un objeto para el usuario.
    4. Restituye el acceso de una tabla para que nadie pueda insertar las filas en la tabla.

    Vea estos enlaces útiles:

    1. Rendimiento de la statement VIEW vs. SQL
    2. ¿Es una vista más rápida que una simple consulta?
    3. Mysql VIEWS vs. PHP query
    4. ¿Las vistas de MySQL son dinámicas y eficientes?
    5. Vista Materializada vs. Tablas: ¿Cuáles son las ventajas?
    6. ¿Las consultas sobre una vista son más lentas que la ejecución de SQL directamente?
    7. Una solución para los problemas de rendimiento de las vistas TEMPTABLE
    8. Vea las ganancias de rendimiento al usar vistas indexadas en SQL Server

    Creo que el blog de Peter Zaitsev tiene la mayoría de los detalles. Hablando desde la experiencia personal, las vistas pueden funcionar bien si generalmente las mantienes simples. En uno de mis clientes, mantuvieron capas de una vista encima de otra y terminaron en una pesadilla de rendimiento.

    En general, uso vistas para mostrar un aspecto diferente de una tabla. Por ejemplo, en la tabla de mis empleados, muéstreme a los gerentes u oculte el campo de salario de los empleados que no son de recursos humanos. Además, siempre asegúrese de ejecutar EXPLAIN en la consulta y ver para comprender exactamente qué está sucediendo dentro de MySQL.

    Si quieres una prueba sólida en tu escenario, te sugiero que pruebes. Es realmente difícil decir que el uso de vistas siempre es un factor determinante del rendimiento, y una vez más, una visión mal escrita probablemente va a matar tu rendimiento.

    Sirven a su propósito, pero las complejidades e ineficiencias ocultas normalmente superan un enfoque más directo. Una vez encontré una statement de SQL que se unía en dos vistas y las ordenaba los resultados. Las vistas también se clasificaban, por lo que el tiempo de ejecución se podía medir en lo que parecían horas.

    Aquí hay un resumen de tl; dr, puede encontrar evaluaciones detalladas de Peter Zaitsev y de otros lugares.

    Las vistas en MySQL generalmente son una mala idea. En Grooveshark los consideramos dañinos y siempre los evitamos. Si tiene cuidado, puede hacer que funcionen pero, en el mejor de los casos, son una forma de recordar cómo seleccionar datos o evitar que tenga que volver a escribir uniones complicadas. En el peor de los casos, pueden causar ineficiencias masivas, ocultar la complejidad, provocar subsecciones anidadas accidentales (que requieren tablas temporales y conducen al agolpamiento del disco), etc.

    Lo mejor es simplemente evitarlos y mantener sus consultas en código.

    Si estamos discutiendo “si usa vistas, cómo garantizar el rendimiento”, y no el efecto de rendimiento de las vistas en general, creo que se reduce a la contención (como en usted mismo).

    Puede obtener grandes problemas si solo escribe las vistas para hacer que su consulta sea simple en todos los casos, pero no se preocupe de que sus puntos de vista sean realmente útiles para el rendimiento. Cualquier consulta que hagas al final debería funcionar de manera sensata (mira el ejemplo de comentario de ese enlace por @eggyal). Por supuesto que es una tautología, pero por lo tanto no menos valiosa

    Especialmente debe tener cuidado de no hacer vistas desde vistas, simplemente porque eso podría hacer que sea más fácil hacer esa vista.

    Al final, necesitas ver el motivo por el que estás usando vistas. Cada vez que hagas esto para hacer la vida más fácil al final de la progtwigción, será mejor que tengas un procedimiento almacenado en mi humilde opinión.

    Para mantener las cosas bajo control, es posible que desee escribir por qué tiene una determinada vista y decidir por qué la está utilizando. Por cada ‘nuevo’ uso dentro de su progtwigción, vuelva a verificar si realmente necesita la vista, por qué la necesita y si esto aún le daría una ruta de ejecución sensata. Sigue comprobando tus usos para mantenerlo rápido, y sigue comprobando si realmente necesitas esa vista.

    Una cosa que no se ha mencionado hasta ahora pero que marca una gran diferencia es la indexación adecuada de las tablas fuente de las vistas .

    Como se mencionó anteriormente, las vistas no residen en su base de datos, pero se reconstruyen cada vez . Por lo tanto, todo lo que facilita la reconstrucción del DB aumenta el rendimiento de la vista.

    A menudo, las vistas se unen a los datos de una manera muy mala para el almacenamiento (sin forma normal) pero muy buenos para un uso posterior (hacer análisis, presentar datos al usuario, …) y unir y agregar datos de diferentes tablas.

    Independientemente de si las columnas en las que se realizan las operaciones están indexadas o no, la diferencia en el rendimiento de una vista es enorme. Si las tablas y sus columnas relevantes ya están indexadas, el acceso a la vista no termina al volver a calcular los índices una y otra vez primero . (En el lado negativo, esto se hace cuando los datos se manipulan en las tablas fuente)

    ! ¡Indexe todas las columnas utilizadas en las cláusulas JOINS y GROUP BY en su statement CREATE VIEW!