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