大量非常简单的 sql 查询会影响性能吗?
Posted
技术标签:
【中文标题】大量非常简单的 sql 查询会影响性能吗?【英文标题】:Does a large number of very simple sql queries impact performance? 【发布时间】:2013-02-06 09:59:14 【问题描述】:我有搜索过滤器。每个过滤器/属性都有我需要显示的自己的值。
<?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 的这么多额外请求是否是一件坏事,而不是查询本身。
【问题讨论】:
嗯。FROM eav_attribute_option
建议您可能正在使用 EAV 结构。你是吗?
是的,我在考虑。
【参考方案1】:
您必须对其进行概要分析才能知道您的场景是否需要太长时间。
无论返回多少行,每个查询都有开销。 因此,一般来说,一个返回 20 行的查询优于 20 个每个返回一行的查询。
【讨论】:
我知道一个返回 20 行的查询优于 20 个查询。但总的来说,考虑到小表(500 行)和简单的查询,这对繁忙的网站有很大的影响吗?我希望我可以做一个测试,但是该站点还没有上线,我需要记住当站点繁忙时会发生什么。所以最好多问问有经验的人。 @user1324762:这无法回答。这取决于很多因素。你真的需要测量它。该网站不需要为此在线,只需进行负载或压力测试(-> google)。【参考方案2】:一般来说,在您真正遇到问题之前,我不会担心性能问题。客户反馈可能会在性能成为问题之前很久就提示您重写函数。
话虽如此,RBAR (row by agonizing row) 是数据库的经典性能问题。往返数据库可能很昂贵(特别是如果数据库位于不同的服务器上。)这会让您无法控制加载客户,包括他们的所有订单,这些订单中的所有产品,以及这些产品的属性.在一个微不足道的查询中;每个实体一个查询,这是一场性能灾难。
因此,如果您可以在不做大量工作的情况下避免 RBAR,那么您最好避免这样做。由于您已经写出了这两种情况,因此选择查询较少的情况也无妨。
【讨论】:
【参考方案3】:查询属于典型的 I/O 问题 - 正如其他人所提到的,与应用程序位于不同服务器上的数据库可以(并且很可能会)增加响应时间。还有物理 I/O 的问题 - 如果经常或最近访问数据,则查询返回的结果集可能会被缓存,但如果不是,则有 db 服务器的响应时间。
【讨论】:
【参考方案4】:额外的查询会因上下文切换开销而降低性能(是的,在这种情况下,一个返回 20 行的查询优于 20 个每个返回一行的查询)。
如果这些查询经常运行,如果它们是可缓存的,将会大大加快速度。
【讨论】:
以上是关于大量非常简单的 sql 查询会影响性能吗?的主要内容,如果未能解决你的问题,请参考以下文章
Oracle SQL - FROM 子句中的 JOIN 顺序会影响性能优化吗?