Ответ 1

Зависит.

Это полностью зависит от того, что вы просматриваете через просмотр. Но, скорее всего, сокращение ваших усилий и повышение производительности. Когда оператор SQL ссылается на неиндексированное представление, оптимизатор синтаксического анализатора и запроса анализирует источник как оператора SQL, так и представления, а затем разрешает их в один план выполнения. Существует не один план для оператора SQL и отдельный план для представления.

Вид не скомпилирован. Его виртуальная таблица состоит из других таблиц. Когда вы его создаете, он не находится где-то на вашем сервере. Основные запросы, составляющие представление, подвержены тем же результатам производительности или настройкам оптимизатора запросов. Я никогда не тестировал производительность в представлении VS по его базовому запросу, но я бы предположил, что производительность может незначительно отличаться. Вы можете повысить производительность на индексированном представлении, если данные относительно статичны. Это может быть то, о чем вы думаете, возможно, в терминах "скомпилированных".

Преимущества просмотров:

• Просмотр данных без сохранения данных в объекте.
• Ограничить представление таблицы, т.е. может скрывать некоторые столбцы в таблицах.
• Соедините две или более таблицы и покажите их как один объект для пользователя.
• Отменить доступ к таблице, чтобы никто не мог вставлять строки в таблицу.

Смотрите эти полезные ссылки:

• Производительность инструкции VIEW и SQL
• Является ли просмотр быстрее простого запроса?
• Mysql VIEWS против PHP-запроса
• Являются ли MySql динамическими и эффективными?
• Материализованный взгляд на таблицы: каковы преимущества?
• Является ли запрос более медленным, чем выполнение SQL напрямую?
• Обходной путь для проблем производительности представлений TEMPTABLE
• См. увеличение производительности с помощью индексированных представлений в SQL Server

Ответ 2

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

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

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

Ответ 3

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

Ответ 4

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

Вы можете столкнуться с большими проблемами, если просто напишите мнения, чтобы сделать ваш запрос простым во всех случаях, но не заботьтесь о том, чтобы ваши взгляды действительно были полезны по производительности. Любой запрос, который вы делаете в конце, должен быть работоспособным (см. Пример комментария из этой ссылки by @eggyal). Конечно, тавтология, но, следовательно, не менее ценная

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

В конце вам нужно посмотреть, почему вы используете представления. Каждый раз, когда вы делаете это, чтобы облегчить жизнь в программировании, вам может быть лучше с хранимой процедурой IMHO.

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

Ответ 5

Здесь резюме tl; dr, вы можете найти подробные оценки от Петра Зайцева и в других местах.

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

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

Ответ 6

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

Как упоминалось выше, представления не сохраняются в вашей DB, но перестраиваются каждый раз. Таким образом, все, что облегчает перестройку БД, увеличивает производительность представления.

Часто просмотры объединяют данные очень плохо для хранения (нет нормальной формы), но очень хороши для дальнейшего использования (выполняют анализ, представление данных пользователю и т.д.) и тем самым объединяют и агрегируют данные из разных таблиц,

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

! Индексируйте все столбцы, используемые в предложениях JOINS и GROUP BY в инструкции CREATE VIEW!