有人在回答中提出了 MySQLi multi_query 函数，声称它比循环遍历 3 个单独的查询要好。我试图在谷歌上找到某种答案，但并没有真正满足我的好奇心，所以我希望你们能更好地了解使用它的原因，而不是保存几行代码。
所以这就是我想知道的：
我知道每次访问数据库 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结果，“更高效”的定义就是“更快”。没有针对大量查询或更大结果集的测试，虽然速度很重要，但它不是全部和全部 - 如果我给它无限量的内存，我可以让任何东西运行得非常快，但是尝试同时做任何事情都会惨败。它也不是真实世界的测试，因为最终结果可以通过单个JOINed 查询来实现。不过，它确实会带来一些有趣的阅读。
就我个人而言，我觉得这有点学术，因为如果您一次运行大量语句，90% 的时间它们只会在传递的数据上有所不同，并且查询结构将保持不变——这是一个明显的候选对于准备好的陈述。
上面的答案是错误的。
multi_query 在幕后做什么？
它只是一次将所有查询发送到服务器，同时仅检索第一个查询的结果。因此，实际上，multi_query 是异步查询执行的一种包装器。
multi_query 是否只是简单地访问服务器 x 次并聚合结果？
multi_query 只访问服务器一次。您必须通过调用 next_result手动完成所有其他点击，以获得所有其他查询的结果。
是否存在单个查询可能比多个查询更有效的情况？
这个问题假设存在 multi_query 更快的情况。这是一个有问题的说法。对于通常的查询，网络延迟在整个执行时间中是可以忽略不计的一部分。如果您真的担心速度如此之快，请看一下 HandlerSocket - 它会非常快。但是，对于常规开发，单查询和多查询之间的这种差异将是您最不关心的。如果您关心现实生活，而不是想象中的事情。