что лучше много маленьких запросов или один большой
Что быстрее 50 маленьких или 1, но большой запрос?
Guest
Что быстрее 50 маленьких или 1, но большой запрос?
Что лучше с точки зрения снижения нагрузки на БД, что будет быстрее и т.д.?
Насколько мне известно нагрузку на БД создает не только количество запросов, но и их величина (т.е. размер передаваемой информации в запросе).
Отсюда возникает вопрос. Что лучше? В цикле сделать 50 запросов размер которых будет меньше (но их будет 50, а может и 150-200), или сделать 1 большой запрос в каждой строке которого будет повторяться много ненужных данных. Что как я понимаю увеличит размер запроса и негативно скажется на скорости работы и загрузке БД.
Demiurg
Guest
Новичок
REMO
1 большой, если он не кривой, лучше.
>>в каждой строке которого будет повторяться много ненужных данных.
Что значит много ненужных данных?
Ненужные данные не нужно и выбирать.
Сетевой бобер
Для каждой задачи свой запрос
если у тебя новости, статьи и, скажем, акции в одной таблице и тебе нужно в разные участки страницы вставить блоки по каждому виду статей, то проще со всех точек зрения сделать три разных простых запроса, чем придумывать какой-то сложный запрос, чтобы вытащить все сразу
Новичок
>>новости, статьи и, скажем, акции в одной таблице и тебе нужно в разные участки страницы вставить блоки по каждому виду статей
Такое в цикле обычно не делают.
Новичок
Первым делом, нужно правильно задачу себе представлять и уметь составлять запросы и оптимизировать их, дорога к этому лежит во времени и http://dev.mysql.com/doc/mysql/ru/index.html
Guest
Представлю задачу более подробно.
Есть перечень товаров. Свойства товаров лежат в 2 других таблицах. Из одной мы тянем одно свойство, из другой тянем до 20 других свойств. Все свойства представляют собой текст (не большой, пару слов).
Если делать одним запросом, то количество строк в запросе будет равно количеству товаров * на количество свойств второй таблицы (т.е. до 20). В запросе возникнет много не ненужных, а повторных (я не правильно выразился) данных. Т.е. размер(веса) запроса значительно возрастет. Но это будет один запрос.
С другой стороны мы можем сделать для каждой позиции товара еще один запрос на его свойства (отсюда как раз и вылазит +50 запросов). И тогда избежим увеличения размера(веса) запроса. Но в будещем предвидется увеличение количества товаров до 150 (150 запросов в часто исполняемом скрипте это не слишком)?
Т.е. по сути я хочу понять. Стоит ли ориентироваться в первую очередь на количество запросов или на их вес? Учитывая, что сайт хостится на виртуальном сервере и ресурсы сервера для сайта ограничены.
Эта страница в основном и подвергается использованию. Т.е. скрипт исполнятеся достаточно часто.
Насчет тестировать. А как тестировать нагрузку на БД? Скорость запроса я могу померить. Хотя в принципе я так понимаю, что это вещи взаимосвязанные. Чем меньше скорость, тем меньше нагрузка.
Что быстрее, один большой запрос или много маленьких запросов?
Я работал на разные компании, и я заметил, что некоторые из них предпочитают иметь представления, которые присоединятся к столу со всеми его «родственниками». Но затем в приложении несколько раз нам нужно использовать только 1 столбец.
Так будет ли быстрее просто делать простые выборки, а затем «присоединять» их к системному коду?
Система может быть php, java, asp, любой язык, который подключается к базе данных.
Вы можете разложить объединение, выполнив несколько запросов к одной таблице вместо многопользовательского объединения, а затем выполнив объединение в приложении. Например, вместо этого одного запроса:
Вы можете запустить эти запросы:
С какой стати ты это сделал? На первый взгляд это выглядит расточительно, потому что вы увеличили количество запросов, не получив ничего взамен. Однако такая реструктуризация может дать существенные преимущества в производительности:
В результате объединения операций в приложении могут быть более эффективными, когда вы кэшируете и повторно используете много данных из предыдущих запросов, распределяете данные по нескольким серверам, заменяете объединения IN() списками или объединение ссылается на одну и ту же таблицу несколько раз.
НАБЛЮДЕНИЯ
Мне нравится первый пункт, потому что InnoDB немного неуклюж, когда проверяет кеш запросов.
Что касается последнего пункта, я написал сообщение от 11 марта 2013 г. ( есть ли разница в выполнении между условием JOIN и условием WHERE? ), В котором описывается алгоритм вложенного цикла. Прочитав его, вы увидите, насколько хорошей может быть декомпозиция соединения.
Некоторые могут быть довольны производительностью и больше не трогать код. Другие просто не понимают, что есть большие преимущества, которые можно получить, если они попытаются присоединиться к композиции.
Много маленьких запросов против нескольких больших запросов (API Design)
В настоящее время я работаю над проектом с организацией следующим образом:
В качестве аргумента, скажем, клиенту сначала нужен список элементов из каждого стороннего API. Из этого списка будет выбран элемент, и в этот момент клиент должен увидеть полное содержимое элемента, а также ответы (то есть комментарии) на элемент. Я пытаюсь выбрать между тремя вариантами:
А ля карт
При таком подходе у меня будет 3 отдельных конечных точки на моем сервере: одна для получения списка элементов, одна для получения основного контента для элемента и одна для получения ответов элемента.
Серверный кеш
В этом запросе я бы сделал один вызов на мой сервер, чтобы «извлечь» все данные для всех источников. Затем данные будут кэшироваться на сервере. Тогда клиент будет иметь те же конечные точки REST, что и раньше, за исключением того, что между вызовами не будет много ожидания, так как мой сервер уже имеет данные и просто должен передать их клиенту.
Клиентский кеш
Этот сценарий похож на предыдущий, за исключением того, что клиент делает только один запрос к серверу: предоставьте мне все данные. Отсюда ответственность за сохранение данных и их правильное использование лежит на клиенте.
Я не уверен, какой подход лучше, или, может быть, я упускаю очевидное решение. Любой совет будет принята с благодарностью!
Следует помнить одну вещь: ожидаемая задержка в сети (т. Е. Время проверки связи) между вашими клиентами и вашим сервером. В ситуации с высокой задержкой и в остальном хорошей пропускной способностью многие маленькие запросы будут работать значительно хуже, чем один большой.
Недавно я участвовал в проекте коллективного веб-приложения на основе базы данных, в котором одна из команд находится в Индии (остальные в США). У нас есть один экземпляр базы данных, размещенный в нашем офисе в США, к которому разработчики подключают экземпляры нашего локального веб-сервера. Мой рабочий стол может быть в пятидесяти футах и двух прыжках локальной сети от экземпляра базы данных, и производительность в порядке.
Когда мы впервые начали работать с разработчиками в Индии, они испытывали огромное время ожидания при запуске приложения и переходе от страницы к странице. Мы говорим здесь десять минут ожидания. Оказывается, это произошло потому, что время пинга
200 мс от их рабочих столов до нашего сервера базы данных dev умножалось на множество кратких запросов к базе данных. Мой локальный пинг 0,5 мс был настолько тривиальным, что общение между веб-сервером и сервером базы данных никогда не имело значения. Это был первый раз, когда у нас было географическое разделение между веб-сервером и сервером базы данных.
В нашем случае решение состояло в том, чтобы клонировать сервер базы данных и подготовить копию в Индии, но суть здесь в том, чтобы помнить, что если ваш клиент и сервер находятся далеко друг от друга, задержка сети будет умножена на количество соединений через провод. Пропускная способность, как только соединение установлено, обычно гораздо меньше проблем.
Эти три параметра не являются взаимоисключающими, вы можете использовать комбинацию как кэшей на стороне клиента, так и на стороне сервера. Однако некоторые данные, например комментарии, могут устареть, если хранятся в кеше слишком долго. Учитывая, что вы не можете проверить, так ли это, вам, вероятно, следует вообще не хранить его. С другой стороны, контент обычно не меняется кардинально, поэтому не было бы вреда для кэширования его на стороне сервера, а затем для его предварительной загрузки на стороне клиента, чтобы снизить задержку.
Что лучше: 10 простых запросов или 1 большой.
Платформа 1С:Предприятие 8.1 позволяет работать с пакетами запросов. В пакетном запросе тексты запросов разделяются символом «;». Запросы исполняются последовательно, при этом временные таблицы, которые были созданы во время исполнения какого-либо запроса будут существовать до окончания исполнения всего пакета запроса или до исполнения в пакете запроса, уничтожающего данную временную таблицу. Например:
«ВЫБРАТЬ
Первый запрос создает временную таблицу, данные из которой используются во втором запросе.
Если объекту Запрос, исполняющему пакетный запрос, установлен менеджер временных таблиц, временные таблицы, которые не были уничтожены в рамках пакетного запроса, сохранятся в установленном менеджере. В тексте пакетного запроса возможно использование и уничтожение временных таблиц, которые существовали в установленном менеджере временных таблиц на момент запуска пакета на исполнение.
Кроме метода Выполнить(), последовательно выполняющего все запросы пакета и возвращающего результат последнего запроса в пакете, платформа 1С:Предприятие 8 предоставляет еще один метод – ВыполнитьПакет(). Этот метод последовательно выполняет все запросы и возвращает массив результатов для каждого запроса из пакета в последовательности расположения запросов в тексте пакета. Результатом выполнения запроса на уничтожение временной таблицы является значение Неопределено, которое также помещается в массив результатов. (с) V8AddDoc81.htm
Форум PHP программистов ► PHP практикум ► PHP + SQL
Здесь живет 
Профиль
Группа: Форумчанин 
Сообщений: 346
Пользователь №: 19306
На форуме:
Карма: 1
Не курю:
9 лет, 3 месяца, 24 дня
Здравствуйте. Вот столкнулся с проблемой:
На последнем шаге нужно вывести товар. Но так как база очень обширная (14гб) и 77 таблиц, то id в одной таблице, картинки в другой, описание в 3-ей, цена в 4-ой, критерии товара в 5-ой.
Так вот, существует 2 варианта: написать один большой запрос на получение сразу всех записей, удовлетворяющих входному параметру. Собственно вот он:
Плюсы одного запроса :
-он один
-легко формируется массив данных и легко обрабатывается в шаблоне
-не нужно городить кучу кода по обработке всех 4-х
Плюсы 5 запросов:
— легкие в отладке, тк если все объеденить в один сложно отслеживать ошибки в выводе результатов
Формирование страницы происходит примерно за одинаковое время что там, что там. +- 3-5 сек если товаров около 100, и до десятых секудны если до 2-3
Так вот хотел бы поинтересоваться, вообще такой запрос приемлимый со столькими объединениями? Или лучше все таки по хуже в обработке, но разбить на несколько частей этот запрос?