2

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

<?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 的这么多额外请求是否是一件坏事，而不是查询本身。

4

4 回答 4

0

一般来说，在您真正遇到问题之前，我不会担心性能。客户反馈可能会在性能成为问题之前很久就提示您重写函数。

话虽如此，RBAR（逐行痛苦）是数据库的经典性能问题。到数据库的往返可能很昂贵（特别是如果数据库位于不同的服务器上。）这会让您无法控制加载客户，包括他们的所有订单，这些订单中的所有产品，以及这些产品的属性. 在一个微不足道的查询中；每个实体一个查询，这是一场性能灾难。

因此，如果您可以在不做大量工作的情况下避免 RBAR，那么您最好避免使用 RBAR。由于您已经写出了这两种情况，因此选择查询较少的情况不会有什么坏处。

于 2013-02-06T10:24:39.420 回答
0

您必须对其进行分析以了解您的场景是否需要太长时间。

无论返回的行数如何，每个查询都有开销。
因此，一般而言，一个返回 20 行的查询优于 20 个每个返回一行的查询。

于 2013-02-06T10:05:50.060 回答
0

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

于 2013-02-20T00:57:33.620 回答
0

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

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

于 2013-05-23T06:56:54.720 回答