大量非常简单的SQL查询是否会影响性能？

Question

我有搜索过滤器。 每个过滤器/属性都有自己需要显示的值。

<?php foreach(getAdditionalFilters() as $attributeName => $filterData): ?>
<ul>
  <?php showLiCheckBoxes($attributeName); ?>
</ul>     
<?php endforeach; ?> 

有两种显示过滤器的方法：

1。

function showLiCheckBoxes($attribute,$checked=null){
    $CI = get_instance();
    $CI->load->model('helper_model');
    $allAttrOptions = $CI->helper_model->getAttrOptions($attribute);
    foreach($allAttrOptions as $key => $option){         
      //print html of inputs like <li><input type='checkox' value='{$option['optionId']}...
    };    
}

function getAttrOptions($attrCode){
      $sql = "SELECT option_id as optionId, label FROM eav_attribute_option
              INNER JOIN eav_attribute USING(attr_id)
              WHERE code='$attrCode'";
      $query = $this->db->prepare($sql);        
      $query->execute(); 
      $query->setFetchMode(PDO::FETCH_ASSOC);
      return $query->fetchAll();      
}

2。

function showLiCheckBoxes($attribute,$checked=null){
    foreach(Attributes::${$attribute} as $key => $value){        
      //print html of inputs like <li><input type='checkox' value='{$option['optionId']}...
    };    
}

class Attributes 
{  

    public static $education        = array(0 => 'No answer', 
                                            1 => 'High school',
                                            2 => 'Some college',
                                            3 => 'In college',
                                            4 => 'College graduate',
                                            5 => 'Grad / professional school',                                    
                                            6 => 'Post grad');   
     public static $...

因此，第一种方式是将属性选项存储在数据库中，并且您可以看到，对于每个属性，都会进行额外的查询 。 第二种方法是将属性选项存储在数组中。

我不是在问哪种方法是正确的，因为这里还没有写其他一些事实。 我要问的是，如果只对500个行的表eav_attribute_option进行20个额外的非常简单的查询会对性能产生任何影响。 我应该关心它还是在这里写的查询如此简单，表是否如此之小，以至于根本没有任何区别？

当然，我也可以使用1个查询进行查询，但这不再是问题。 我在问自己，是否有太多对sql server的额外请求可能是一件坏事，而不是查询本身。

Answer 1

您必须对其进行概要分析，以了解您的方案是否花费太长时间。

每个查询都有开销，无论返回的行数如何。
因此，通常，一个返回20行的查询要好于返回20行的每个查询。

Answer 2

通常，在您遇到实际问题之前，我不会担心性能。 客户反馈可能会提示您在性能出现问题之前很长时间重写功能。

话虽这么说，RBAR（ 逐行地折腾 ）是数据库的经典性能问题。 往返数据库可能会很昂贵（尤其是如果数据库位于其他服务器上）。这使您无法控制加载客户及其所有订单，这些订单中的所有产品以及这些产品的属性。 。 在一个查询中，这很简单。 每个实体只有一个查询，这是性能的灾难。

因此，如果无需大量工作就可以避免RBAR。 既然您已经写完了两种方案，那么选择查询较少的方案就不会有什么坏处。

Answer 3

查询属于经典的I / O问题-正如其他人提到的那样，与应用程序不同的服务器上的数据库可以（而且很可能会）增加响应时间。 物理I / O也是一个问题-如果频繁或最近访问数据，则可能会缓存查询返回的结果集，但如果不这样做，则存在db服务器的响应时间。

Answer 4

额外的查询会因上下文切换开销而降低性能（是的，在这种情况下，一个返回20行的查询要好于返回20行的每个查询）。

如果这些查询经常运行，那么如果它们是可缓存的，它将大大加快速度。