Does a large number of very simple sql queries impact performance? - mysql

Question

I have search filters. Each filter/attribute have own values I need to show.
<?php foreach(getAdditionalFilters() as $attributeName => $filterData): ?>
<ul>
<?php showLiCheckBoxes($attributeName); ?>
</ul>
<?php endforeach; ?>
There are two ways how to display filters:
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 $...
So in the first way attributes options are stored in database and as you can see for each attribute extra query is made. In the second way attributes options are stored in array.
I am not asking which way is correct because there are some other facts not wrote here. What I am asking is just that if 20 extra very simple queries for table eav_attribute_option with only 500 rows could make any performance impact. Should I care about it or is the query I wrote here so simple and table is so small that it won't make any difference at all?
Of course I could make this also with 1 query, but this is not the question again. I was asking myself if so many extra requests to sql server could be a bad thing, not the query itself.

Answer 1

You have to profile it to know if it takes too long for your scenario.
Every query has an overhead, regardless of the number of rows returned.
So, in general, one query that returns 20 rows is better than 20 queries that return one row each.

Answer 2

In general, I wouldn't worry about performance until you actually have an issue. Customer feedback may prompt you to rewrite the function long before performance becomes a problem.
Having said that, RBAR (row by agonizing row) is THE classic performance issue with databases. A round trip to the database can be expensive (especially if the database is on a different server.) This gets out of hand of you load customers, with all their orders, with all the products in those orders, with the properties of those products. In one query that's trivial; with one query per entity, it's a performance disaster.
So you'd do well to avoid RBAR if you can do so without a lot of work. Since you've already written out both scenario's, it couldn't hurt to go for the one with less queries.

Answer 3

Queries fall into the classic I/O issue - as someone else mentioned, a database on a different server than the application can (and most likely will) increase response time. There's also the issue of physical I/O - result sets returned for queries might be cached if the data is frequently or recently accessed, but if not, there's the response time of the db server.

Answer 4

Extra queries can degrade performance due to context switching overheads (yes, in that case, one query that returns 20 rows is better than 20 queries that return one row each).
If these queries are run very often, it would speed things up considerably if they were cacheable.