Comments on: MySQL: Followup on UNION for query optimization, Query profiling http://www.mysqlperformanceblog.com/2006/08/14/mysql-followup-on-union-for-query-optimization-query-profiling/ Everything about MySQL Performance Mon, 08 Sep 2008 04:38:10 +0000 http://wordpress.org/?v=2.5.1 By: peter http://www.mysqlperformanceblog.com/2006/08/14/mysql-followup-on-union-for-query-optimization-query-profiling/#comment-313019 peter Fri, 13 Jun 2008 16:57:05 +0000 http://www.mysqlperformanceblog.com/2006/08/14/mysql-followup-on-union-for-query-optimization-query-profiling/#comment-313019 Tobias, UNION generally has larger overhead than IN or OR. It is faster in the cases when it allows better execution plan - avoiding full table scan with OR on different columns (before 5.0) or avoiding filesort. Tobias,

UNION generally has larger overhead than IN or OR. It is faster in the cases when it allows better execution plan - avoiding full table scan with OR on different columns (before 5.0) or avoiding filesort.

]]> By: peter http://www.mysqlperformanceblog.com/2006/08/14/mysql-followup-on-union-for-query-optimization-query-profiling/#comment-313018 peter Fri, 13 Jun 2008 16:55:11 +0000 http://www.mysqlperformanceblog.com/2006/08/14/mysql-followup-on-union-for-query-optimization-query-profiling/#comment-313018 Brian, You would need to test large IN vs BETWEEN this likely to be rather workload dependent. Note very large IN sets (especially cascaded) may cause MySQL to abandon full range optimization - in this case there is it should become slower than BETWEEN. Brian,

You would need to test large IN vs BETWEEN this likely to be rather workload dependent.
Note very large IN sets (especially cascaded) may cause MySQL to abandon full range optimization - in this case there is it should become slower than BETWEEN.

]]> By: Tobias http://www.mysqlperformanceblog.com/2006/08/14/mysql-followup-on-union-for-query-optimization-query-profiling/#comment-312978 Tobias Fri, 13 Jun 2008 14:44:39 +0000 http://www.mysqlperformanceblog.com/2006/08/14/mysql-followup-on-union-for-query-optimization-query-profiling/#comment-312978 Peter, one question on UNION vers. IN : Is it a general rule that UNION is faster then IN? Another thing I experienced is a serious speed-advantage when using UNION instead of long OR-Statements. Is this correct? Thank You! Peter,

one question on UNION vers. IN : Is it a general rule that UNION is faster then IN? Another thing I experienced is a serious speed-advantage when using UNION instead of long OR-Statements. Is this correct?

Thank You!

]]> By: brian http://www.mysqlperformanceblog.com/2006/08/14/mysql-followup-on-union-for-query-optimization-query-profiling/#comment-271184 brian Wed, 09 Apr 2008 00:52:48 +0000 http://www.mysqlperformanceblog.com/2006/08/14/mysql-followup-on-union-for-query-optimization-query-profiling/#comment-271184 Hi Peter, I wonder if you might be able to expand on the limitations of using "IN" vs. "BETWEEN" in terms of a point of decreasing returns? (e.g., at what point do the number of values in "IN" become large enough that there is no performance difference between using "IN" and "BETWEEN"?) Also, does the performance increase involved in using "IN" apply to JOIN queries as well? Is there a difference in how "IN" is treated when the query in question utilizes a JOIN? Of course, one thing I love about this site is that often times you tell us how we can measure for ourselves. I can see if one query is faster than the other, but am still not so awesome at unwrapping things to determine why. Thanks. Hi Peter,

I wonder if you might be able to expand on the limitations of using “IN” vs. “BETWEEN” in terms of a point of decreasing returns? (e.g., at what point do the number of values in “IN” become large enough that there is no performance difference between using “IN” and “BETWEEN”?)

Also, does the performance increase involved in using “IN” apply to JOIN queries as well? Is there a difference in how “IN” is treated when the query in question utilizes a JOIN?

Of course, one thing I love about this site is that often times you tell us how we can measure for ourselves. I can see if one query is faster than the other, but am still not so awesome at unwrapping things to determine why.
Thanks.

]]> By: Jorje http://www.mysqlperformanceblog.com/2006/08/14/mysql-followup-on-union-for-query-optimization-query-profiling/#comment-182508 Jorje Tue, 30 Oct 2007 04:29:21 +0000 http://www.mysqlperformanceblog.com/2006/08/14/mysql-followup-on-union-for-query-optimization-query-profiling/#comment-182508 Great article...One quaestion : Can I use UNION, if I don't have certain values for a field ( like age=18, age=19 ) ?? What if I have a query like : SELECT * from table WHERE type = 1 and value >= 150.4 and value 31 order by score desc limit 20 ??? How can I avoid "using filesort", in this case ??? Thanx Great article…One quaestion : Can I use UNION, if I don’t have certain values for a field ( like age=18, age=19 ) ?? What if I have a query like :

SELECT * from table WHERE type = 1 and value >= 150.4 and value 31 order by score desc limit 20 ???

How can I avoid “using filesort”, in this case ???

Thanx

]]> By: peter http://www.mysqlperformanceblog.com/2006/08/14/mysql-followup-on-union-for-query-optimization-query-profiling/#comment-24535 peter Fri, 15 Dec 2006 10:24:37 +0000 http://www.mysqlperformanceblog.com/2006/08/14/mysql-followup-on-union-for-query-optimization-query-profiling/#comment-24535 Mocanu, Nope there is a serious difference. Assuming you have query which matches 50.000 rows and you want to get and display only 10 of them - a way most search applications work. In case you're using simply IN you will get 50.000 rows stored in temporary table and sorted by filesort - going to be quite slow. If you're using UNION - each of the queries in the UNION will produce only 10 rows, using index for sorting not filesort. If you have 5 queries in the UNION you will have 50 rows in the temporary table which you still need to do filesort for. Sorting 50.000 rows vs 50 rows is the difference here, now avoiding filesort completely :) Mocanu,

Nope there is a serious difference. Assuming you have query which matches 50.000 rows and you want to get and display only 10 of them - a way most search applications work. In case you’re using simply IN you will get 50.000 rows stored in temporary table and sorted by filesort - going to be quite slow.

If you’re using UNION - each of the queries in the UNION will produce only 10 rows, using index for sorting not filesort. If you have 5 queries in the UNION you will have 50 rows in the temporary table which you still need to do filesort for.

Sorting 50.000 rows vs 50 rows is the difference here, now avoiding filesort completely :)

]]> By: Sorin Mocanu http://www.mysqlperformanceblog.com/2006/08/14/mysql-followup-on-union-for-query-optimization-query-profiling/#comment-24532 Sorin Mocanu Fri, 15 Dec 2006 10:00:38 +0000 http://www.mysqlperformanceblog.com/2006/08/14/mysql-followup-on-union-for-query-optimization-query-profiling/#comment-24532 Peter, I think you are making a mistake regarding the filesort - in both cases (when using "IN (18,19,20)" and when using "UNION") mysql makes a temporary table of about the same size on which it does a filesort. Basically, in the first version the results are filtered by age and then a temporary table is created with the *filtered* records. Peter, I think you are making a mistake regarding the filesort - in both cases (when using “IN (18,19,20)” and when using “UNION”) mysql makes a temporary table of about the same size on which it does a filesort. Basically, in the first version the results are filtered by age and then a temporary table is created with the *filtered* records.

]]> By: MySQL Performance Blog » ORDER BY … LIMIT Performance Optimization http://www.mysqlperformanceblog.com/2006/08/14/mysql-followup-on-union-for-query-optimization-query-profiling/#comment-2147 MySQL Performance Blog » ORDER BY … LIMIT Performance Optimization Fri, 01 Sep 2006 16:37:49 +0000 http://www.mysqlperformanceblog.com/2006/08/14/mysql-followup-on-union-for-query-optimization-query-profiling/#comment-2147 [...] Even though it looks quite similar to previous one it is a lot different as there are multiple category_id values in the list now so index on (category_id, date_created) can't be used directly. Index on date_created separately would still work. The good from performance standpoint (even though a bit ugly) will be UNION workaround I already wrote about. [...] [...] Even though it looks quite similar to previous one it is a lot different as there are multiple category_id values in the list now so index on (category_id, date_created) can’t be used directly. Index on date_created separately would still work. The good from performance standpoint (even though a bit ugly) will be UNION workaround I already wrote about. [...]

]]>