Я работал на разные компании, и я заметил, что некоторые из них предпочитают иметь представления, которые присоединятся к столу со всеми его «родственниками». Но затем в приложении несколько раз нам нужно использовать только 1 столбец.

Так будет ли быстрее просто делать простые выборки, а затем «присоединять» их к системному коду?

Система может быть php, java, asp, любой язык, который подключается к базе данных.

Таким образом, вопрос заключается в том, что быстрее перейти от серверной части (php, java, asp, ruby, python ...) к базе данных, выполнить один запрос, чтобы получить все необходимое, или перейти со стороны сервера в базу данных и запустить запрос, который только получить столбцы из одной таблицы в то время?

Что бы ответить на ваш вопрос - тема «СОВМЕСТНОЕ ДЕКОМПОЗИЦИЯ».

Согласно странице 209 Книги

Вы можете разложить объединение, выполнив несколько запросов к одной таблице вместо многопользовательского объединения, а затем выполнив объединение в приложении. Например, вместо этого одного запроса:

SELECT * FROM tag
JOIN tag_post ON tag_post.tag_id = tag.id
JOIN post ON tag_post.post_id = post.id
WHERE tag.tag = 'mysql';

Вы можете запустить эти запросы:

SELECT * FROM tag WHERE tag = 'mysql';
SELECT * FROM tag_post WHERE tag_id=1234;
SELECT * FROM post WHERE post.id IN (123,456,567,9098,8904);

С какой стати ты это сделал? На первый взгляд это выглядит расточительно, потому что вы увеличили количество запросов, не получив ничего взамен. Однако такая реструктуризация может дать существенные преимущества в производительности:

• Кэширование может быть более эффективным. Многие приложения кэшируют «объекты», которые отображаются непосредственно в таблицы. В этом примере, если объект с тегом mysqlуже кэширован, приложение пропустит первый запрос. Если вы найдете в кэше сообщения с идентификатором 123, 567 или 908, вы можете удалить их из IN()списка. Кэш запросов также может извлечь выгоду из этой стратегии. Если часто изменяется только одна из таблиц, декомпозиция объединения может уменьшить количество недействительных кэшей.
• Выполнение запросов по отдельности может иногда уменьшить конкуренцию за блокировку
• Выполнение объединений в приложении облегчает масштабирование базы данных путем размещения таблиц на разных серверах.
• Сами запросы могут быть более эффективными. В этом примере использование IN()списка вместо объединения позволяет MySQL сортировать идентификаторы строк и извлекать строки более оптимально, чем это возможно при объединении.
• Вы можете уменьшить избыточный доступ к строкам. Выполнение объединения в приложении означает получение каждой строки только один раз, тогда как объединение в запросе - это, по сути, денормализация, которая может многократно обращаться к одним и тем же данным. По той же причине такая реструктуризация может также уменьшить общий сетевой трафик и использование памяти.
• В некоторой степени вы можете рассматривать эту технику как реализацию хэш-соединения вручную вместо алгоритма вложенных циклов, который MySQL использует для выполнения соединения. Хеш-соединение может быть более эффективным.

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

НАБЛЮДЕНИЯ

Мне нравится первый пункт, потому что InnoDB немного неуклюж, когда проверяет кеш запросов.

• Sep 05, 2012: Стоит ли когда-нибудь издержек частой аннулирования кэша запросов?
• Jun 07, 2014: Почему query_cache_type отключен по умолчанию, начиная с MySQL 5.6?

Что касается последнего пункта, я написал сообщение от 11 марта 2013 г. ( есть ли разница в выполнении между условием JOIN и условием WHERE? ), В котором описывается алгоритм вложенного цикла. Прочитав его, вы увидите, насколько хорошей может быть декомпозиция соединения.

Что касается всех остальных пунктов книги , разработчики действительно смотрят на производительность как на практический результат. Некоторые полагаются на внешние средства (вне приложения) для повышения производительности, такого как использование быстрого диска, получение большего количества процессоров / ядер, настройка механизма хранения и настройка файла конфигурации. Другие будут сгибаться и писать лучший код. Некоторые могут прибегнуть к кодированию всей бизнес-аналитики в хранимых процедурах, но по-прежнему не применяют декомпозицию объединения (см. Каковы аргументы против или для размещения логики приложения на уровне базы данных? Вместе с другими публикациями). Все зависит от культуры и терпимости каждого разработчика.

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

Для тех разработчиков, которые готовы ...

ДАЙТЕ ЭТО ПОПРОБУЙТЕ !!!

В Postgres (и, вероятно, в любой СУБД в аналогичной степени, MySQL в меньшей степени) почти все запросы выполняются намного быстрее.

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

Не говоря уже о дополнительной работе, которую нужно выполнить в клиенте, объединяя результаты, которые обычно гораздо медленнее. СУБД специализируется на таких задачах, а операции основаны на исходных типах данных. Запрещается textприводить к промежуточным результатам или возвращать их для собственных типов клиентов, что может даже привести к менее правильным (или неправильным!) Результатам. Подумайте о числах с плавающей точкой ...

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

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

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

Связанный вопрос по SO:

• Как лучше? Выполнение расчетов в SQL или в вашем приложении

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