因此，我们正在构建此应用程序，其中数据检索基于小型模块化查询。所以对于一个产品来说就像是：
$product = $this->product->getProductData($prod_id); //get main product record
$locations = $this->locations->getAvailableLocations($prod_id); //sale locations
$comments = $this->feedback->getFeedback($prod_id,'COMMENTS'); //user comments
另一方面，我们也可以这样做：$this->getAllProductData($id)
基本上有一个SQL：
get * from product_data
left join locations on <...>
left join comments on <...>
从programming的角度来看，第一个选项使我们更容易处理数据，混合和匹配构建单独的流程/用户体验等。我们关注的是 - 从performance角度来看这将是当产品在数十万行中运行时会成为问题吗？
答案 0 :(得分：0)
使用您的第二个示例（一个查询中的所有联接）。只要你有一个关于“prod_id”的索引以及你正在过滤或加入的任何其他东西，数据库查询优化器就会做一些聪明的事情，比如看到prod_id只会返回一些记录，并且首先要做的就是查询尽可能快。一般来说，查询优化器非常非常好。
答案 1 :(得分：0)
对于简单连接，你可能对一个sql语句很好，但根据我的经验，当涉及更多表时，多个单独的查询对性能更好。
我曾经在一个网站上工作，产品信息分散在七个不同的表中，通常只有两到三个表需要加入。但是在一个页面上我们有一个复杂的搜索功能需要查看它们中的所有七个，因此在该页面上我们编写了代码以在一个语句中连接所有表。它运行良好，直到几个月后，它逐渐变慢，直到它完全不会加载。
我们浏览了所有表格并确保所有内容都已正确索引，并且没有任何修复它。我们注意到sql语句本身都运行正常，所以我们最终把它拆分成单独的语句并修复它，不必再回头再看一遍。
答案 2 :(得分：0)
每次执行SQL语句都会产生开销。发送到服务器的数据包，解析的SQL文本，验证语法正确的语句（关键字，逗号，parens等），语句验证语义正确（标识符引用表，列，函数等存在且用户具有足够的特权，评估可能的执行计划并选择最佳计划，执行计划（获取锁，访问缓冲区中的数据等），实现结果集（元数据和值），返回调用者，释放锁，清理资源等。在客户端，有检索结果集，获取行和关闭语句的开销。
一般来说，使用较少的语句检索所需的实际数据会更有效，但如果这些信息返回不需要的大量信息则不会。如果我们只需要20行，那么我们会在查询中添加LIMIT 20。如果我们只需要特定product_id的行WHERE product_id = 42。
当我们看到重复执行基本相同的语句的紧密循环时，这是一个告诉故事标志，即开发人员正在处理数据RBER（通过难以排列的行），而不是作为集合。
底线，这取决于用例。有时候，用一些较小的陈述来代替一个巨大的陈述会更有效率。