有人在回答中提到了 MySQLi multi_query 函数，声称它比遍历 3 个单独的查询要好。我试图在 Google 上找到某种答案，但并没有真正满足我的好奇心，所以我希望你们能更好地了解使用它的原因，而不是节省几行代码。
这就是我想知道的：
我知道每次访问数据库 3 次以获得 100 万个项目并将其粉碎成一个巨大的对象对内存使用不利，但我知道它的存在必须有原因，而且我也确信存在是应该避免的时候。我希望能更好地理解它，以便在需要时将其放入我的技巧包中。
感谢您的宝贵时间！
【问题讨论】：
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() 可能会更好，因为返回值只是成功/失败，并且内存消耗会很轻。
您必须权衡所有因素，例如您正在做什么、预计需要多长时间、（数据库）服务器和客户端之间的网络延迟、服务器上的可用资源（主要是内存）以及客户等...并根据具体情况进行处理。
我在不久前发现了这个record of some performance testing，其结论是使用multi_query() 可以提高整体效率。 然而 测试用例只是简单地运行 4 个查询，每个 SELECT 查询一个结果，“更高效”的定义就是“更快”。没有测试更多的查询或更大的结果集，虽然速度很重要，但它不是最重要的和最终的——如果我给它无限量的内存，我可以让任何东西运行得非常快，但是尝试同时做任何事情都会惨败。这也不是真实世界的测试，因为最终结果可以通过单个 JOINed 查询来实现。不过，它确实会带来一些有趣的阅读。
我个人觉得这有点学术，因为如果您同时运行大量语句，90% 的时间它们只会在传递的数据和查询结构上有所不同将保持不变 - 这显然是准备好的语句的候选者。
【讨论】：
上面的答案是错误的。
multi_query 在后台做了什么？
它只是一次将所有查询发送到服务器，同时只检索第一个查询的结果。因此，实际上，multi_query 是一种异步的包装器查询执行。
multi_query 是否只是简单地访问服务器 x 次并聚合结果？
multi_query 只访问服务器一次。为了获得所有其他查询的结果，您必须手动通过调用 next_result 进行所有其他点击。
是否存在单个查询可能比多个查询更有效的情况？
这个问题假设存在 multi_query 更快的情况。这是一个有问题的说法。对于通常的查询，网络延迟在整个执行时间中是可以忽略不计的一部分。如果您真的担心速度这样，请查看 HandlerSocket - 它会非常快。但是，对于常规开发，单查询和多查询之间的这种差异将是您最不关心的。如果您关心现实生活，而不是想象中的事情。
【讨论】：