Las vistas en MySQL no están indexadas, por lo que, por su propia naturaleza, requieren un análisis completo cada vez que se accede a ellas. En términos generales, esto hace que las vistas solo sean útiles para situaciones en las que tiene una consulta estática bastante compleja que devuelve un pequeño conjunto de resultados y planea capturar todo el conjunto de resultados cada vez.
Editar: Por supuesto, Views usará los índices en las tablas subyacentes para que la Vista en sí misma esté optimizada (de lo contrario, no tendría ningún sentido usarla), pero debido a que no hay índices en una Vista, no es posible para una consulta DONDE en la Vista a optimizar.
La construcción de índices para Vistas sería costosa de todos modos porque, si bien no he intentado perfilar ninguna Vista, estoy bastante seguro de que se construye una tabla temporal detrás de escena y luego se devuelve el conjunto de resultados. Ya lleva mucho tiempo construir la tabla temporal, no me gustaría una vista que también intente adivinar qué índices se necesitan. Lo que trae a colación el segundo punto, que es que MySQL actualmente no ofrece un método para especificar qué índices usar para una Vista, entonces, ¿cómo sabe qué campos deben indexarse? ¿Supone según su consulta?
Podría considerar usar una Tabla temporal porque entonces puede especificar índices en campos en la tabla temporal. Sin embargo, por experiencia esto tiende a ser muy, muy lento.
Si todo lo que contiene esta vista es SELECCIONAR TODO DE table1, table2, table3; entonces tendría que preguntar por qué esta consulta debe estar en una Vista. Si por alguna razón es absolutamente necesario, es posible que desee utilizar un procedimiento almacenado para encapsular la consulta, ya que podrá obtener un rendimiento optimizado mientras mantiene el beneficio de una llamada más simple a la base de datos para el conjunto de resultados.
