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