2013-02-06 28 views
2

我有搜索過濾器。每個過濾器/屬性都有我需要顯示的自己的值。大量非常簡單的sql查詢是否會影響性能?

<?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服務器可能是一件壞事,而不是查詢本身。

+0

嗯。 'FROM eav_attribute_option'表明您可能正在使用EAV結構。你是? –

+0

是的,我正在考慮。 – user1324762

回答

0

您必須對其進行配置以瞭解它是否需要太長時間才能滿足您的方案。

無論返回的行數是多少,每個查詢都會有開銷。
因此,一般而言,返回20行的一個查詢優於每個返回一行的20個查詢。

+0

我知道一個返回20行的查詢優於20個查詢。但一般來說,考慮到小表(500行)和簡單的查詢,這是否會在繁忙的網站上產生巨大的影響?我希望我可以做一個測試,但該網站還沒有在線,我需要記住什麼時候該網站會很忙。所以最好問問有更多經驗的人。 – user1324762

+0

@ user1324762:這是不可能回答的。這取決於很多因素。你真的需要測量它。該網站不需要爲此在線,只需進行負載或壓力測試( - >谷歌)。 –

0

一般來說,我不會擔心性能,直到你真的有問題。在性能成爲問題之前,客戶反饋可能會提示您重寫該功能。

話雖如此,RBAR(row by agonizing row)是數據庫的經典性能問題。往返數據庫可能會很昂貴(特別是如果數據庫位於不同的服務器上)。這會使您無法將客戶的所有訂單以及這些訂單中的所有產品加載到這些產品的屬性中。在一個微不足道的查詢中,每個實體有一個查詢,這是性能災難。

因此,如果沒有很多工作就可以避免RBAR,那麼你就會做得很好。既然你已經寫出了這兩個場景,那麼用較少的查詢就不會傷害到它。

0

查詢屬於經典的I/O問題 - 正如別人提到的,與應用程序不同的服務器上的數據庫可能(並且很可能會)增加響應時間。還有物理I/O的問題 - 如果數據頻繁或最近訪問過,返回的查詢結果集可能會被緩存,但如果沒有,則會有數據庫服務器的響應時間。

0

額外的查詢會由於上下文切換開銷而降低性能(是的,在這種情況下,返回20行的一個查詢優於每個返回一行的20個查詢)。

如果這些查詢經常運行,如果它們是可緩存的,它將大大提高速度。