Я нашел публикацию на форумах MySQL с 2005 года, но ничего более недавнего. Исходя из этого, это невозможно. Но многое может измениться через 3-4 года.
То, что я ищу, - это способ иметь индекс над представлением, но просматриваемая таблица остается неиндексированной. Индексация вредит процессу записи, и эта таблица написана довольно часто (до такой степени, что индексирование замедляет все до обхода). Однако этот недостаток индекса делает мои запросы болезненно медленными.
Я не думаю, что MySQL поддерживает материализованные представления, которые вам нужны, но в любом случае это не поможет вам в этой ситуации. Независимо от того, находится ли указатель в представлении или в базовой таблице, его нужно будет записать и обновить в какой-то момент во время обновления базовой таблицы, так что это все равно вызовет проблемы с скоростью записи.
Лучше всего будет создавать сводные таблицы, которые периодически обновляются.
Рассматривали ли вы абстрагирование данных обработки транзакций от данных аналитической обработки, чтобы они могли быть специализированными для удовлетворения своих уникальных требований?
Основная идея состоит в том, что у вас есть одна версия данных, которая регулярно изменяется, это будет сторона обработки транзакций и требует интенсивных нормализаций и легких индексов, чтобы операции записи выполнялись быстро. Вторая версия данных структурирована для аналитической обработки и, как правило, менее нормализована и более сильно индексируется для быстрой отчетности.
Данные, структурированные вокруг аналитической обработки, обычно строятся вокруг методологии куба хранилища данных, состоящей из таблиц фактов, которые представляют стороны куба и таблицы измерений, которые представляют края куба.
Flexviews поддерживает материализованные представления в MySQL, отслеживая изменения в базовых таблицах и обновляя таблицу, которая функционирует как материализованное представление. Этот подход означает, что SQL, поддерживаемый представлением, немного ограничен (поскольку процедуры ведения журнала изменений должны определять, в каких таблицах он должен отслеживать изменения), но насколько я знаю, это самый близкий доступ к материализованным представлениям в MySQL.
Вам нужно только одно индексированное представление? Маловероятно, что запись в таблицу с одним индексом была бы разрушительной. Нет ли первичного ключа?
Если каждая запись велика, вы можете повысить производительность, выяснив, как ее сократить. Или сократите длину требуемого индекса.
Если это таблица с записью (т.е. вам не нужно делать обновления), в MySQL может быть смертельно опасно начать ее архивирование или иным образом удалить записи (и индексные ключи), требуя, чтобы индекс начинал заполнять (повторное использование) слотов из удаленных ключей, а не просто добавления новых значений индекса. Непротиворечивый, но в этом случае вам лучше с большой таблицей.