这是一个在我所在的地方一直弹出的主题。对于返回行列表的查询类型，我们通常希望执行进一步的查询，以收集有关该特定行的更多信息，这通常包括本身返回行列表的查询。一个这样的例子是一个订单系统，它返回一个客户列表，每个客户'行'也可能显示他们的订单列表(可能在弹出对话框中)。
通常"更好":
- 执行单个查询，在可能的情况下使用
GROUP_CONCAT，并以编程方式拆分结果(对返回的连接长度有限制) - 在遍历'父查询'的结果时对每一行执行'子查询'
- 执行一个"父查询"以返回客户列表，并使用SQL
IN关键字执行一个"订单"查询，以匹配从前一个查询返回的customer_ID。通过循环客户查询的结果，我们可以看到customer_ID是否存在于订单查询中，并显示匹配的订单。 - 作为和when执行第二个查询。理由是，我们并不总是希望看到每个父结果的子结果(使用web应用程序，我们可以使用AJAX来抓取子结果)
- 别的吗?
我一直倾向于第2点，因为从概念上讲，它似乎是最干净的解决方案，但我忍不住认为它是一个资源消耗者。对一组特定的结果进行我们自己的基准测试，#3是最快的。#4似乎应该是最快的，因为一些应用程序不需要显示所有结果，但是，目的可能是让结果准备好并等待，而不是再次往返检索该行的子数据。我不完全确定FETCH_ASSOC等的机制是如何工作的，但任何建议都是非常欢迎的!
我认为#3更好。我建议获取所有客户，然后是该客户的所有订单列表(customer_ID IN(…))，然后如果需要，在php端将订单发送给正确的客户。
通过这种方式，您只获得两个包含所有信息的查询，并且可以避免调度部分(取决于该查询之后要执行的逻辑)。
请记住，查询的大部分开销来自查询本身(传输查询，然后获取数据)数据库是高度优化的事情，如搜索和连接，所以选择数据不是瓶颈(直到你达到非常高的数字)，所以它是另一个解决方案。
另外，如果您使用IN选择with index，数据库甚至不需要搜索术语，它只会查看索引，然后直接到每一行。
根据您的应用程序，如果用户只查看一个或两个订单列表，则显示100个客户，则#4更好。
无论如何，考虑在循环中进行sql查询通常是一个糟糕的实践/糟糕的设计/糟糕的逻辑。