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