В современном мире скорость является ключевым фактором. При создании приложений и программного обеспечения с базой данных нам необходим быстрый доступ к данным за минимально возможное время. Для этого мы реализуем различные меры базы данных, включая материализованные представления.
Однако, в отличие от PostgreSQL или Oracle Database, MySQL изначально не поддерживает материализованные представления, что может быть огромным недостатком. Однако это не причина прекращать использование MySQL, потому что это отличная база данных для основных приложений.
В этой статье мы быстро обсудим, что такое материализованные представления, как они работают, примеры, в которых они применимы, и как реализовать материализованные представления в MySQL.
Материализованные представления — это предварительно рассчитанные результаты запроса, хранящиеся в таблице. В отличие от стандартного представления MySQL, материализованное представление не является окном в таблице базы данных; в нем хранятся актуальные данные.
Эти типы объектов очень полезны, когда вам нужен немедленный доступ к данным, а для обработки обычного запроса MySQL потребуется время. Хорошим примером являются случаи с большим набором данных, который требует большого количества вычислений.
Поскольку материализованные представления содержат реальные данные, они требуют обновления, чтобы отразить значения, обновленные по тому же запросу. Интервал обновления для материализованного представления зависит от сохраненного содержимого и скорости изменения данных.
Простой ответ — НЕТ. В MySQL нет единой команды, которую можно было бы выполнить для получения материализованного представления. Например, вы не можете ввести команду ниже и получить то, что вам нужно:
Mysql > CREATE MATERIALIZED VIEW…
К счастью, с помощью нескольких уловок и инструментов, изначально предоставляемых MySQL, мы можем реализовать материализованное представление, подобное тому, которое изначально предоставляется PostgreSQL, Oracle и другими.
В этом разделе я покажу вам способ реализации материализованного представления в MySQL.
Предположим, у нас есть схема с именем (mv), в которой есть таблица с именем info, используемая для хранения информации о продажах, как показано в запросах ниже:
CREATE SCHEMA mv; USE mv; CREATE TABLE info ( id INT PRIMARY KEY AUTO_INCREMENT, seller_id INT, _date date, amount INT ); INSERT INTO info(seller_id, _date, amount) VALUES (101, "2021-06-05", 2000), (111, "2021-06-05", 6000), (121, "2021-05-05", 10000);
Используя приведенный выше пример таблицы, мы можем создать материализованную таблицу, в которой хранится информация о запросе, например, показанном ниже:
SELECT seller_id, _date, SUM(amount * 12 * 8) as total_amount FROM info WHERE _date < CURRENT_DATE ORDER BY seller_id;
Запрос может показаться неэффективным, учитывая размер базы данных и информацию, хранящуюся в таблице выше, потому что он будет обрабатываться очень быстро. Однако в большой базе данных с большим количеством информации запрос, подобный приведенному выше, может занять некоторое время для обработки.
В таком случае мы можем создать материализованное представление для хранения информации из вышеуказанного запроса, что позволяет нам быстрее получать доступ к информации, просто выбирая ее из представления, а не используя каждый раз необработанный запрос.
Чтобы создать материализованное представление, мы можем создать таблицу с результатами запроса выше:
CREATE TABLE materialized_view ( SELECT seller_id, _date, SUM(amount * 12 * 8) as total_amount FROM info WHERE _date < CURRENT_DATE ORDER BY seller_id );
Как вы теперь знаете, материализованное представление содержит реальные данные; это не снимок стола.
Это означает, что если основная таблица обновлена, данные в материализованной таблице представления потребуют обновления.
Чтобы обновить материализованное представление, мы можем использовать процедуру, показанную ниже:
DELIMITER $$ CREATE PROCEDURE refresh_materialv( OUT dev INT ) BEGIN TRUNCATE TABLE materialized_view; INSERT INTO materialized_view SELECT seller_id, _date, SUM(amount * 12 * 8) as total_amount FROM info WHERE _date SELECT * FROM materialized_view; +-----------+------------+--------------+ | seller_id | _date | total_amount | +-----------+------------+--------------+ | 101 | 2021-06-05 | 172800 | +-----------+------------+--------------+
Затем попробуйте обновить данные, хранящиеся в основной таблице, как:
INSERT INTO info(seller_id, _date, amount) VALUES (101, "2021-06-05", 200), (111, "2021-06-05", 600), (121, "2021-05-05", 1000), ("131", "2021-06-05", 6000), ("141", "2021-06-05", 1400);
Наконец, попробуйте обновить данные таблицы materialized_view с помощью процедуры, которую мы создали выше.
CALL refresh_materialv(@dev); SELECT * FROM materialized_view;
Это отображает обновленные значения в таблице материализованного представления.
В этой статье обсуждалось, что такое материализованные представления, как они работают и как их можно реализовать при использовании MySQL. Попробуйте применить концепции, изложенные в этом руководстве, чтобы освоить работу с материализованными представлениями.
Тогда какой смысл в Varchar (кроме задания длины), если во всём он проигрывает? А если учесть, что при работе с базами TEXT значительно быстрее, то какой смысл ограничивать длину данных?
Ну как минимум можно задать индекс для Varchar