Когда использовать представления в MySQL?


54

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

Одна из причин, по которой я предпочел бы использовать представления, заключается в том, что схема базы данных была разработана нашим администратором из Ruby, и я не знаком с Ruby. Я могу попросить, чтобы таблицы были созданы, но требует дополнительного шага, и я хотел бы больше гибкости при разработке / тестировании новых объединений.

Я начал использовать представления после ответа на связанный вопрос о SO ( когда использовать R, когда использовать SQL ). Ответ, получивший наибольшее количество голосов, начинается: «выполняйте манипуляции с данными в SQL до тех пор, пока данные не окажутся в одной таблице, а затем сделайте все остальное в R.»

Я начал использовать представления, но столкнулся с несколькими проблемами с представлениями:

  1. запросы гораздо медленнее
  2. Представления не выгружаются из рабочей базы данных в резервную копию, которую я использую для анализа.

Подходят ли представления для этого использования? Если да, то следует ли ожидать снижения производительности? Есть ли способ ускорить запросы на просмотры?


Похоже, что здесь уместны представления, но я не уверен, что может вызвать замедление при их запросах.
FrustratedWithFormsDesigner

@FrustratedWithFormsDesigner Есть ли какая-нибудь диагностика, которая может помочь (кроме создания воспроизводимого примера)? Тот же сложный запрос занимает <4 с, когда выполняется непосредственно в соединенных таблицах, и> 25 с, когда выполняется для представлений. Ожидается ли, что просмотры не будут снижать производительность?
Дэвид Лебауэр

Прошло много времени с тех пор, как я использовал MySQL, поэтому я не могу сказать точно.
FrustratedWithFormsDesigner

Я использую MySQL, и я скажу вам, что представления ужасны, непригодны для использования, когда вы достигаете 100K и выше, просто используйте прямые запросы, где вы можете контролировать, какие поля возвращать и что объединять, чтобы использовать
Стивен Сенкомаго Мусоке

Ответы:


43

Представления в MySQL обрабатываются с использованием одного из двух разных алгоритмов: MERGEили TEMPTABLE. MERGEэто просто расширение запроса с соответствующими псевдонимами. TEMPTABLEкак бы это ни звучало, представление помещает результаты во временную таблицу перед выполнением предложения WHERE, и для него нет индексов.

Третья опция - это UNDEFINED, что говорит MySQL выбрать подходящий алгоритм. MySQL попытается использовать, MERGEпотому что это более эффективно. Главное предостережение:

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

  • Агрегатные функции (SUM (), MIN (), MAX (), COUNT () и т. Д.)

  • DISTINCT

  • ГРУППА ПО

  • HAVING

  • ПРЕДЕЛ

  • СОЮЗ или СОЮЗ ВСЕХ

  • Подзапрос в списке выбора

  • Относится только к буквальным значениям (в этом случае нет базовой таблицы)

[SRC]

Я бы рискнул предположить, что ваши VIEWS требуют алгоритма TEMPTABLE, вызывающего проблемы с производительностью.

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

Однако в конце туннеля может появиться некоторый свет по этой проблеме временных таблиц, не содержащих индексы (вызывающих полное сканирование таблиц). В 5.6 :

В случаях, когда для подзапроса в предложении FROM требуется материализация, оптимизатор может ускорить доступ к результату, добавив индекс в материализованную таблицу. ... После добавления индекса оптимизатор может обрабатывать материализованную производную таблицу так же, как обычную таблицу с индексом, и аналогичным образом получает выгоду от сгенерированного индекса. Затраты на создание индекса незначительны по сравнению со стоимостью выполнения запроса без индекса.

Как указывает @ypercube, MariaDB 5.3 добавила такую ​​же оптимизацию. Эта статья имеет интересный обзор процесса:

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


Я не проводил тестирование по этим утверждениям, но MariaDB 5.3 (недавно выпущенный как стабильный) имеет некоторые значительные улучшения в оптимизаторе, в том числе Views :Fields of merge-able views and derived tables are involved now in all optimizations employing equalities
ypercubeᵀᴹ

@ypercube спасибо за эту ссылку ... похоже, в MySQL 5.6 есть хотя бы оптимизация добавления индекса в производные таблицы.
Дерек Дауни

14

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

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

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

Существует хорошая документация, которая может вам помочь: http://www.toadworld.com/LinkClick.aspx?fileticket=3qbwCnzY/0A=&tabid=234


5
Я не согласен с тем, что представления являются (только) инструментами безопасности. Их можно использовать таким образом, но мы используем их для устранения сложности запросов, которые наши разработчики отчетов используют на регулярной основе.
JHFB

2
@JHFB: Я согласен с вами, но, может быть, это только то, как это работает в MySQL, где кажется, что представление подвергается серьезным потерям производительности?
FrustratedWithFormsDesigner

Замечательный момент @frustratedwithformsdesigner - я давно использую MySQL.
JHFB

1
@JHFB взгляды на Mysql - большая проблема! mysqlperformanceblog.com/2007/08/12/…
Ренье Морилла

2
@RainierMorilla Представления ухудшают производительность !! ??
Сухайл Гупта

-2

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


2
Не очень понятно, что вы хотите сказать, и как это решает проблемы, изложенные в оригинальном сообщении. Возможно, вы захотите перечитать вопрос, но в любом случае рассмотрите возможность расширения своего ответа, чтобы было понятнее, как его можно применить к проблеме ОП.
Андрей М
Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.