As visualizações no MySQL não são indexadas, portanto, por sua própria natureza, exigem uma varredura completa toda vez que são acessadas. De um modo geral, isso torna o Views realmente útil apenas para situações em que você tem uma consulta estática bastante complexa que retorna um pequeno conjunto de resultados e planeja obter todo o conjunto de resultados todas as vezes.

Editar: É claro que as Views usarão os índices nas tabelas subjacentes para que a própria View seja otimizada (caso contrário, não faria nenhum sentido usar), mas como não há índices em uma View, não é possível uma consulta WHERE em a Visualização a ser otimizada.

Construir índices para Views seria caro de qualquer maneira porque, embora eu não tenha tentado criar o perfil de nenhuma View, tenho quase certeza de que uma tabela temporária é construída nos bastidores e, em seguida, o conjunto de resultados é retornado. Já leva muito tempo para construir a tabela temporária, eu não gostaria de uma visão que também tentasse adivinhar quais índices são necessários. O que traz o segundo ponto, que é que o MySQL atualmente não oferece um método para especificar quais índices usar para uma View, então como ele sabe quais campos precisam ser indexados? Ele adivinha com base em sua consulta?

Você pode considerar usar uma Tabela temporária porque então você pode especificar índices em campos na tabela temporária. No entanto, por experiência, isso tende a ser muito, muito lento.

Se tudo o que esta visão contiver for um SELECT ALL FROM table1, table2, table3; então eu teria que perguntar por que essa consulta precisa estar em uma exibição? Se, por algum motivo, for absolutamente necessário, você pode querer usar um procedimento armazenado para encapsular a consulta, pois poderá obter desempenho otimizado enquanto mantém o benefício de uma chamada mais simples ao banco de dados para o conjunto de resultados.