Возможно ли иметь индексированное представление в MySQL?

Question

Я нашел сообщение на форумах MySQL с 2005 года , но ничего более нового, чем это. Исходя из этого, это невозможно. Но многое может измениться через 3-4 года.

То, что я ищу, - это способ индексирования представления, но просматриваемая таблица остается неиндексированной. Индексирование вредит процессу записи, и эта таблица записывается довольно часто (до такой степени, что индексирование замедляет все для сканирования). Однако это отсутствие индекса делает мои запросы мучительно медленными.

Answer 1

Я не думаю, что MySQL поддерживает материализованные представления, которые вам нужны, но в любом случае это не поможет вам в этой ситуации. Независимо от того, находится индекс в представлении или в базовой таблице, он должен быть записан и обновлен в некоторый момент во время обновления базовой таблицы, так что это все равно вызовет проблемы со скоростью записи.

Лучше всего было бы создавать сводные таблицы, которые периодически обновляются.

Answer 2

Рассматривали ли вы абстрагирование данных обработки транзакций от данных аналитической обработки, чтобы они оба могли быть специализированными для удовлетворения их уникальных требований?

Основная идея заключается в том, что у вас есть одна версия данных, которая регулярно модифицируется, это будет сторона обработки транзакций, требующая интенсивной нормализации и легких индексов, чтобы операции записи были быстрыми. Вторая версия данных структурирована для аналитической обработки и имеет тенденцию быть менее нормализованной и более интенсивно индексируемой для быстрых операций отчетности.

Данные, структурированные вокруг аналитической обработки, как правило, строятся вокруг методологии куба хранилища данных, состоящей из таблиц фактов, представляющих стороны куба, и таблиц измерений, представляющих края куба.

Answer 3

Flexviews поддерживает материализованные представления в MySQL, отслеживая изменения в базовых таблицах и обновляя таблицу, которая функционирует как материализованное представление. Этот подход означает, что SQL, поддерживаемый представлением, немного ограничен (поскольку подпрограммы регистрации изменений должны выяснить, какие таблицы следует отслеживать для изменений), но, насколько я знаю, это наиболее близко вы можете получить к материализованным представлениям в MySQL. .

Answer 4

Вы хотите только один индексированный просмотр? Маловероятно, что запись в таблицу с одним индексом будет такой разрушительной. Нет ли первичного ключа?

Если каждая запись велика, вы можете улучшить производительность, выяснив, как ее сократить. Или сократите длину нужного вам индекса.

Если это таблица только для записи (т.е. вам не нужно делать обновления), в MySQL может быть смертельно опасно начинать ее архивирование или иным образом удалять записи (и ключи индекса), требуя, чтобы индекс начал заполняться (повторное использование) слотов из удаленных ключей, а не просто добавление новых значений индекса. Противоречиво, но в этом случае вам лучше с большим столом.