Просмотры MySQL: используйте или не используйте

Question

Я хотел спросить, действительно ли View стоит использовать.

По моему мнению, представление - это действительно просто запрос, и каждый раз, когда вы запрашиваете представление, представление затем снова запускает свой собственный запрос, чтобы получать свежие/данные uptodate.

Это звучит для меня как 2 запроса. не будет быстрее просто выполнить требуемый запрос и пропустить представление?

Обратите внимание: я бы использовал простые представления, но даже это было довольно сложно. Я предполагаю, что применяется тот же принцип.

Мой тип представления - скажем, 3 таблицы с 6 столбцами каждый - и 2 столбца каждого времени добавляются в представление с помощью нескольких уравнений математики, чтобы улучшить данные прикосновением.

Что делают другие? Пропустить или использовать их?

Answer 1

Вы правы, что представления не предназначены для производительности в MySQL.

Что они предназначены, чтобы сделать другие запросы, построенные на них, более простыми для чтения, и чтобы другие пользователи и программисты имели больше шансов правильно использовать данные. Подумайте о них как о способе практически де-нормализации данных, не принимая при этом размер/производительность, фактически де-нормализуя данные.

Как самый простой случай, давайте просто возьмем заказы и позиции. Каждый заказ имеет позицию.

Таблица заказов может иметь следующие столбцы:

ID 
Status 
Created_at 
Paid_on 

И таблица line_items может иметь следующие столбцы:

LI_ID 
order_id 
sku_id 
quantity 
price 

Что вы найдете, при написании кода и запросов является то, что вы будете делать следующее соединение:

orders 
    join line_items on line_items.order_id = orders.id 

Этот кулон d быть упрощена путем создания представления:

create view 'order_lines' as 
select * from orders 
    join line_items on line_items.order_id = orders.id 

Таким образом, ваш запрос будет идти от:

select orders.id, sum(price) from orders 
    join line_items on line_items.order_id = orders.id 
    where created_at >= '2011-12-01' and created_at < '2012-01-01 
    group by orders.id; 

к:

select id, sum(price) from order_lines 
    where created_at >= '2011-12-01' and created_at < '2012-01-01 
    group by id; 

БД будет выполнять обе эти точно так же, но один легче читать. По общему признанию, в этом случае, не намного проще читать, но проще читать и кодировать.

Answer 2

Оптимизатор запросов обычно может комбинировать запрос вида с запросом, который использует представление таким образом, что выполняется только один запрос, поэтому возражение, которое вы просматриваете, на самом деле не применяется.

Answer 3

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

Answer 4

Смотрите также:

MySQL VIEW as performance troublemaker

View vs. Table Valued Function vs. Multi-Statement Table Valued Function

Should I use a view, a stored procedure, or a user-defined function?

С уважением

Answer 5

Представления могут быть предоставлены для приложений или пользователей, которые необходимы прямой вперед представление данных, ISN Обязательно в одной таблице (или ограниченных полях из одной таблицы). Это означает, что им не нужно понимать данные и как они относятся - они просто получают нужные им данные. Вы создаете сложный запрос, оптимизируете его, и они просто используют полученный результат.