Кто-то поднял функцию multi_query MySQLi в ответ, утверждая, что было бы лучше, чем цикл через 3 отдельных запроса. Я попытался ответить на какой-то ответ Google, но на самом деле не получил ничего, что действительно удовлетворяло мое любопытство, поэтому я надеюсь, что вы, ребята, можете лучше понять причины его использования, а не сохранять несколько строк кода.
Итак, вот что мне интересно:
Я знаю, что поражение базы данных 3 раза за миллион элементов и разбиение их на один огромный объект не подходит для использования памяти, но я знаю, что для его существования должна быть причина, и я также уверен, что бывают случаи, когда его следует избегать. Я надеюсь лучше понять это, чтобы я мог поместить это в свою сумку трюков, когда возникнет такая необходимость.
Спасибо за ваше время!
What is multi_query doing under the hood? – Просто отправляйте все запросы на сервер одновременно, а не поочередно, и получая все результаты за один раз. Ничего сложнее.
Does multi_query simply hit the server x number of times and aggregates the results? – Он дважды «ударяет» по серверу – один раз для отправки запросов и один раз для получения результатов.
Is there a case where single queries may be more efficient than multiple queries? – зависит от того, как вы определяете «эффективный». multi_query() светится в сети, но память тяжелая, выполняется query() в цикле наоборот.
Для многих SELECT которые возвращают большие результирующие наборы, потеря в потреблении памяти, вероятно, значительно перевешивает прирост в плане сети, и большую часть времени вам лучше будет выдавать запросы и обрабатывать результаты, установленные по одному за раз – хотя это зависит от того, что вы делаете с данными. Но если вам нужно запустить много операторов UPDATE , вполне вероятно, что multi_query() будет лучше, поскольку возвращаемые значения будут просто успешными / неудачными, а потребление памяти будет светлым.
Вам придется взвесить все факторы, как то, что вы делаете, сколько времени вы ожидаете от этого, латентность сети между сервером (клиентом) и клиентом, доступными ресурсами (в основном памятью) на сервере и клиентом и т. Д. , и т. д. … и принимать его в каждом отдельном случае.
Я нашел эту запись некоторых проверок производительности, сделанных некоторое время назад, когда вывод заключается в том, что от использования multi_query() можно получить общий коэффициент эффективности. Однако тестовый сценарий просто запускал 4 запроса, каждый из которых SELECT единственный результат, а определение «более эффективно» просто «быстрее». Нет тестирования для большего количества запросов или больших наборов результатов, и, хотя скорость важна, это не все и все – я могу сделать что-нибудь невероятно быстро, если я дам ему неограниченное количество памяти, но попытка сделать что-то одновременно потерпит неудачу. Это также не тест реального мира, так как конечный результат может быть достигнут с помощью одного запроса JOIN ed. Тем не менее, это делает некоторые интересные чтения.
Лично я считаю, что это несколько академическое, потому что, если вы одновременно запускаете большой набор операторов, то в 90% случаев они будут меняться только в передаваемых данных, а структура запросов останется прежней – что является очевидным кандидатом для подготовленных заявлений.
Ответ выше неправильный.
Что делает multi_query под капотом?
Он просто отправляет все запросы на сервер за один раз, получая результат только для первого. Таким образом, в действительности, multi_query – своего рода оболочка для выполнения асинхронного запроса.
Использует ли multi_query на сервере x количество раз и агрегирует результаты?
multi_query удаляет сервер только один раз. Все остальные хиты, которые вы должны сделать вручную , вызывая next_result, чтобы получить все результаты других запросов.
Есть ли случай, когда одиночные запросы могут быть более эффективными, чем несколько запросов?
этот вопрос предполагает, что есть случай, когда multi_query быстрее. Это сомнительное утверждение. Для обычного запроса сетевая латентность является незначительной частью всего времени выполнения. Если вы действительно обеспокоены скоростью с такой разницей, взгляните на HandlerSocket – он будет быстро вспыхивать. Однако для регулярной разработки такая разница между одним и несколькими запросами была бы вашей наименее заботой. Если вы занимаетесь вопросами реальной жизни, а не воображаемыми.