Представления в MySQL не индексируются, поэтому по своей природе требуют полного сканирования при каждом обращении к ним. Вообще говоря, это делает представления действительно полезными только в ситуациях, когда у вас довольно сложный статический запрос, который возвращает небольшой набор результатов, и вы планируете получать весь набор результатов каждый раз.
Редактировать: Конечно, представления будут использовать индексы базовых таблиц, так что само представление оптимизируется (иначе они вообще не будут иметь никакого смысла в использовании), но потому что индексы на a View невозможно оптимизировать запрос WHERE в представлении.
Создание индексов для представлений в любом случае было бы дорогостоящим, поскольку, хотя я и не пытался профилировать какие-либо представления, я вполне уверен, что временная таблица создается за кулисами, а затем возвращается набор результатов. Создание временной таблицы уже занимает много времени, я бы не хотел, чтобы представление также пыталось угадать, какие индексы нужны. В связи с этим возникает второй момент: MySQL в настоящее время не предлагает метод, позволяющий указать, какие индексы следует использовать для представления, так как он знает, какие поля необходимо проиндексировать? Это угадывает на основе вашего запроса?
Вы можете рассмотреть возможность использования Temporary Table , потому что тогда вы можете указывать индексы для полей во временной таблице. Однако, по опыту, это очень медленно.
Если все это представление содержит SELECT ALL FROM table1, table2, table3; тогда я должен был бы спросить, почему этот запрос вообще должен быть в представлении? Если по какой-либо причине это абсолютно необходимо, вы можете использовать хранимую процедуру для инкапсуляции запроса, поскольку тогда вы сможете получить оптимизированную производительность, сохраняя при этом преимущество более простого вызова базы данных для набора результатов.