¿Cuándo usar vistas en MySQL?

Al crear tablas a partir de múltiples combinaciones para usar en el análisis, ¿cuándo se prefiere usar vistas en lugar de crear una nueva tabla?

Una razón por la que preferiría usar vistas es que el esquema de la base de datos ha sido desarrollado por nuestro administrador desde Ruby, y no estoy familiarizado con Ruby. Puedo solicitar que se creen tablas, pero requiere un paso adicional y me gustaría tener más flexibilidad al desarrollar / probar nuevas combinaciones.

Comencé a usar vistas después de la respuesta a una pregunta relacionada sobre SO ( cuándo usar R, cuándo usar SQL ). La respuesta más votada comienza "realice las manipulaciones de datos en SQL hasta que los datos estén en una sola tabla y luego haga el resto en R."

Empecé a usar vistas, pero me encontré con algunos problemas con las vistas:

1. las consultas son mucho más lentas
2. Las vistas no se vuelcan de la producción a la base de datos de respaldo que uso para el análisis.

¿Las vistas son apropiadas para este uso? Si es así, ¿debo esperar una penalización de rendimiento? ¿Hay alguna manera de acelerar las consultas sobre las vistas?

Las vistas en MySQL se manejan usando uno de dos algoritmos diferentes: MERGEo TEMPTABLE. MERGEes simplemente una expansión de consulta con los alias apropiados. TEMPTABLEes exactamente lo que parece, la vista coloca los resultados en una tabla temporal antes de ejecutar la cláusula WHERE, y no hay índices en ella.

La opción 'tercera' es UNDEFINED, que le dice a MySQL que seleccione el algoritmo apropiado. MySQL intentará usarlo MERGEporque es más eficiente. Advertencia principal:

Si no se puede usar el algoritmo MERGE, se debe usar una tabla temporal en su lugar. MERGE no se puede usar si la vista contiene alguna de las siguientes construcciones:

• Funciones agregadas (SUM (), MIN (), MAX (), COUNT (), etc.)

• DISTINTO

• AGRUPAR POR

• TENIENDO

• LÍMITE

• UNIÓN o UNIÓN TODOS

• Subconsulta en la lista de selección

• Se refiere solo a valores literales (en este caso, no hay una tabla subyacente)

[src]

Me aventuraría a adivinar que sus VIEWS requieren el algoritmo TEMPTABLE, lo que causa problemas de rendimiento.

Aquí hay una publicación de blog muy antigua sobre el rendimiento de las vistas en MySQL y no parece haber mejorado.

Sin embargo, puede haber algo de luz al final del túnel sobre este tema de las tablas temporales que no contienen índices (lo que causa escaneos completos de tablas). En 5.6 :

Para los casos en que se requiere materialización para una subconsulta en la cláusula FROM, el optimizador puede acelerar el acceso al resultado agregando un índice a la tabla materializada. ... Después de agregar el índice, el optimizador puede tratar la tabla derivada materializada de la misma manera que una tabla habitual con un índice, y se beneficia de manera similar del índice generado. La sobrecarga de la creación del índice es insignificante en comparación con el costo de la ejecución de la consulta sin el índice.

Como señala @ypercube, MariaDB 5.3 ha agregado la misma optimización. Este artículo tiene una visión general interesante del proceso:

La optimización se aplica, entonces la tabla derivada no se pudo fusionar en su SELECT padre, lo que sucede cuando la tabla derivada no cumple con los criterios para una VISTA fusionable

Las vistas son herramientas de seguridad. No desea que un usuario o una aplicación en particular sepa dónde se encuentra su tabla de datos, proporciona una vista solo con las columnas que necesita.

Recuerde que las vistas siempre degradan el rendimiento, consultas similares deben ser procedimientos almacenados y funciones, no vistas.

Para realizar un ajuste de consulta, siga siempre las mejores prácticas, evite el uso de funciones en las cláusulas WHERE, cree índices para acelerar las selecciones, pero no lo abuse, indexa, degrada, inserta, actualiza y elimina.

Hay buena documentación que puede ayudarlo: http://www.toadworld.com/LinkClick.aspx?fileticket=3qbwCnzY/0A=&tabid=234

Creo que las vistas son la estructura predefinida (sin datos) para fusionar tablas en una para superar las consultas de múltiples tablas, que se pueden usar a partir de datos reales para consultas relacionales rápidas ...