MYSQL View vs Select Performance and Latency

0

Каждый фрагмент литературы, который я нашел в этой теме, говорит о том, что преимущество использования представлений заключается в том, насколько чище он делает код. То, что я хотел бы знать, - это если я запускаю несколько выборок один за другим, будет ли латентность (Apache до MySQL до Apache несколько раз) значительно выше, чем при использовании сложного представления. У меня есть сценарий, где я могу взять один из двух подходов:

  1. Используйте индивидуальные запросы. Насколько я понимаю, именно это делает MySQL, даже когда я использую представления. Но будет ли проблема с задержкой, так как я буду выполнять один запрос, разбору его на бэкэнде PHP, чтобы получить фильтры для следующего запроса, а затем отправить этот запрос на сервер MySQL (и так далее, скажем, где-то между 1 и 4 раза, т.е. Я буду запускать от 2 до 5 запросов в целом)? Другими словами, Query1-> PHP → Query2-> PHP ->...
  2. Создавайте сложные виды. Поскольку, вероятно, у меня будут элементы в одной таблице без соответствующей записи в другой, окончательный вид, вероятно, будет иметь несколько UNIONS или JOINS, даже если он создается из двух таблиц. Но поскольку здесь нет вопроса о латентности, и вся обработка и фильтрация выполняется на стороне сервера MySQL, будет ли улучшение производительности?

Что поможет мне быстрее доставлять страницы моим пользователям?

Любая помощь, основанная на фактическом наблюдении или проверенной документации, будет приветствоваться.

Благодарю.

SR

  • 0
    Представьте себе ситуацию, когда пользователь запрашивает данные с веб-сайта. Выполняется несколько запросов, и пользователь их читает. Теперь пользователей становится тысяча. Все они ищут одно и то же значение, с WHERE, UNION, SELECT внутри другого SELECT ... Разве представление не будет лучше? - Глупый пример, но это все. Я использую View и для других областей
  • 0
    Возможное дублирование производительности просмотров MySql
Теги:
select
performance
views
latency

2 ответа

1
Лучший ответ

Это зависит.

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

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

Я говорю, что VIEWs - это синтаксический сахар, а не преимущество в производительности. (@nacho говорит, что это лучше.)

Я создал много сложных страниц, в которых, скажем, 40 запросов. Производительность достойная. Я нахожу любые "медленные" запросы (для этого удобен SlowLog), а затем оптимизируйте их.

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

Поделиться
1

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

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

Ещё вопросы

Сообщество Overcoder
Наверх
Меню