Ever wondered how fast stored routines are in MySQL? I just ran a quick micro-benchmark to compare the speed of a stored function against a “roughly equivalent” subquery. The idea — and there may be shortcomings that are poisoning the results here, your comments welcome — is to see how fast the SQL procedure code is at doing basically the same thing the subquery code does natively (so to speak).
Before we go further, I want to make sure you know that the queries I’m writing here are deliberately mis-optimized to force a bad execution plan. You should never use IN() subqueries the way I do, at least not in MySQL 5.1 and earlier.
I loaded the World sample database and cooked up this query:
|
1 |
<br>select sql_no_cache sum(ci.Population) from City as ci<br> where CountryCode in (<br> select distinct co.Code from Country as co<br> inner join CountryLanguage as cl on cl.CountryCode = co.Code<br> where lower(cl.Language) = 'English');<br>+--------------------+<br>| sum(ci.Population) |<br>+--------------------+<br>| 237134840 | <br>+--------------------+<br>1 row in set (0.23 sec)<br> |
This pretty consistently runs in just about 1/4th of a second. If you look at the abridged explain plan below, you’ll see the query is doing a table scan against the first query, and then executing the subquery for each row:
|
1 |
<br>mysql> explain select ....G<br>*************************** 1. row ***************************<br> id: 1<br> select_type: PRIMARY<br> table: ci<br> type: ALL<br>possible_keys: NULL<br> key: NULL<br> key_len: NULL<br> ref: NULL<br> rows: 4079<br> Extra: Using where<br>*************************** 2. row ***************************<br> id: 2<br> select_type: DEPENDENT SUBQUERY<br>*************************** 3. row ***************************<br> id: 2<br> select_type: DEPENDENT SUBQUERY<br> |
Now I took the subquery and basically rewrote it as a stored function.
|
1 |
<br>mysql> delimiter //<br>mysql> create function speaks_english(c char(3)) returns integer deterministic<br> > begin<br> > declare res int;<br> > select count(distinct co.Code) into res from Country as co inner join CountryLanguage as cl on cl.CountryCode = co.Code where lower(cl.Language) = 'English' and co.Code = c;<br> > return res;<br> > end//<br>mysql> delimiter ;<br> |
Now the query can be rewritten as this:
|
1 |
<br>mysql> select sql_no_cache sum(ci.Population) from City as ci where speaks_english(CountryCode) > 0;<br>+--------------------+<br>| sum(ci.Population) |<br>+--------------------+<br>| 237134840 | <br>+--------------------+<br>1 row in set (1.00 sec)<br> |
If we explain it, we get output similar to the first table shown above, but the further two rows are not shown. The query can’t be optimized to use indexes, and the stored function is opaque to the optimizer. This is why I purposefully wrote the subquery badly in the first query! (If you think of a better way to compare apples and uhm, apples… please comment).
The poorly-optimized-subquery portion of the query essentially happens inside that function now.
And it’s four times slower, consistently, and that’s all I wanted to show here. Thanks for reading.
