Comments on: Derived Tables and Views Performance http://www.mysqlperformanceblog.com/2006/08/31/derived-tables-and-views-performance/ Percona's MySQL & InnoDB performance and scalability blog Sat, 11 Feb 2012 16:45:54 +0000 hourly 1 http://wordpress.org/?v=3.2.1 By: Vincent VAN HOLLEBEKE http://www.mysqlperformanceblog.com/2006/08/31/derived-tables-and-views-performance/comment-page-1/#comment-886323 Vincent VAN HOLLEBEKE Tue, 07 Feb 2012 18:53:42 +0000 http://www.mysqlperformanceblog.com/2006/08/31/derived-tables-and-views-performance/#comment-886323 Hi, Is the problem still existing in actual versions of MySQL, or is it solved ? Thank you. Hi,

Is the problem still existing in actual versions of MySQL, or is it solved ?

Thank you.

]]> By: John Larsen http://www.mysqlperformanceblog.com/2006/08/31/derived-tables-and-views-performance/comment-page-1/#comment-446423 John Larsen Thu, 15 Jan 2009 16:34:00 +0000 http://www.mysqlperformanceblog.com/2006/08/31/derived-tables-and-views-performance/#comment-446423 Baron: You know what your right. Somehow in the past I was able to get a view to do this, think it was for a aggregated value (view was an aggregate) which was then trimmed down in queries to the view to be pieces of the aggregate. Was able to get better performance at the time on multiple queries in a row (first query of a connection was slow later queries were instant) then a straight query to the table as the view was holding the aggregate data used for selection of its parts. Can't seem to figure out how I did it now as I didn't specify any special notation to it (like TEMPTABLE). Baron: You know what your right. Somehow in the past I was able to get a view to do this, think it was for a aggregated value (view was an aggregate) which was then trimmed down in queries to the view to be pieces of the aggregate. Was able to get better performance at the time on multiple queries in a row (first query of a connection was slow later queries were instant) then a straight query to the table as the view was holding the aggregate data used for selection of its parts. Can’t seem to figure out how I did it now as I didn’t specify any special notation to it (like TEMPTABLE).

]]> By: Baron Schwartz http://www.mysqlperformanceblog.com/2006/08/31/derived-tables-and-views-performance/comment-page-1/#comment-446407 Baron Schwartz Thu, 15 Jan 2009 14:37:38 +0000 http://www.mysqlperformanceblog.com/2006/08/31/derived-tables-and-views-performance/#comment-446407 John, that is incorrect. Views do not store their data. You are mixing the TEMPTABLE algorithm (which creates an internal temp table for the duration of the query) and the query cache (which stores result sets until underlying tables change or other conditions require discarding them). And views only permit usage of the underlying table's indexes if the MERGE algorithm is used. John, that is incorrect. Views do not store their data. You are mixing the TEMPTABLE algorithm (which creates an internal temp table for the duration of the query) and the query cache (which stores result sets until underlying tables change or other conditions require discarding them). And views only permit usage of the underlying table’s indexes if the MERGE algorithm is used.

]]> By: John Larsen http://www.mysqlperformanceblog.com/2006/08/31/derived-tables-and-views-performance/comment-page-1/#comment-446160 John Larsen Thu, 15 Jan 2009 04:33:33 +0000 http://www.mysqlperformanceblog.com/2006/08/31/derived-tables-and-views-performance/#comment-446160 Ari: Did you try immediently running it again with a different where this is where views shine. Yes unless specifically made not to a view will run the exact select stored in the view. But untill the table it is based upon changes relative to that view a temporary table will be stored containing the full view. As the view temp table won't need recreating a second run with where would be faster than the second run of a regular select because you have less columns to deal with. A view will generally retain it parents indexes. Ari: Did you try immediently running it again with a different where this is where views shine. Yes unless specifically made not to a view will run the exact select stored in the view. But untill the table it is based upon changes relative to that view a temporary table will be stored containing the full view. As the view temp table won’t need recreating a second run with where would be faster than the second run of a regular select because you have less columns to deal with. A view will generally retain it parents indexes.

]]> By: zblmw http://www.mysqlperformanceblog.com/2006/08/31/derived-tables-and-views-performance/comment-page-1/#comment-349989 zblmw Fri, 29 Aug 2008 03:17:11 +0000 http://www.mysqlperformanceblog.com/2006/08/31/derived-tables-and-views-performance/#comment-349989 珠宝联盟网 中国珠宝联盟网(zblmw.com)是一家服务于中国大陆及全球华人社群的领先在线珠宝媒体及增值资讯服务提供商。中国珠宝网站拥有多家地区性网站，以服务大中华地区与海外华人以及珠宝企业为己任，通过为广大网民和政府企业用户提供网络媒体及娱乐、在线用户付费增值/无线增值服务和电子政务解决方案等在内的一系列服务。 专业珠宝门户——中国珠宝网站预计2008年在全球范围内注册用户超过500万，日浏览量能最高突破8000万次，将成为中国大陆及全球华人社群中最受推崇的行业互联网品牌。 高效的整合营销服务——凭借领先的技术和优质的服务，中国珠宝网站会深受广大网民的欢迎并能享有极高的声誉。 http://www.zblmw.com 珠宝联盟网

中国珠宝联盟网(zblmw.com)是一家服务于中国大陆及全球华人社群的领先在线珠宝媒体及增值资讯服务提供商。中国珠宝网站拥有多家地区性网站，以服务大中华地区与海外华人以及珠宝企业为己任，通过为广大网民和政府企业用户提供网络媒体及娱乐、在线用户付费增值/无线增值服务和电子政务解决方案等在内的一系列服务。

专业珠宝门户——中国珠宝网站预计2008年在全球范围内注册用户超过500万，日浏览量能最高突破8000万次，将成为中国大陆及全球华人社群中最受推崇的行业互联网品牌。

高效的整合营销服务——凭借领先的技术和优质的服务，中国珠宝网站会深受广大网民的欢迎并能享有极高的声誉。

http://www.zblmw.com

]]> By: javatopia http://www.mysqlperformanceblog.com/2006/08/31/derived-tables-and-views-performance/comment-page-1/#comment-217722 javatopia Fri, 14 Dec 2007 22:18:14 +0000 http://www.mysqlperformanceblog.com/2006/08/31/derived-tables-and-views-performance/#comment-217722 We ran into this problem just recently on a real world query. In this case the query was of this form: select * from (big inner query) foo order by a, b, c The choice to use this query syntax was for programming brevity - it's easier to rename the output columns from the big inner query using the outer query instead. Alas, though, the nasty version of this query took over 2.5 minutes to run on 53,000 record scans. The version without the outer select ran in 9/10th of a second on the same record space. The EXPLAIN clearly showed that the outer select was doing a full table scan on the results instead of using the indices. Unbelievable. I ran the exact same nasty query in Microsoft SQL Server 2000 and it performed as expectd - lightning fast execution. The execution plan showed the effective use of table indices and much smarter insertion of the sub-query's grouping clauses. MySQL needs quite a bit of real-world tuning to make it a believable enterprise database. You get what you pay for, right? We ran into this problem just recently on a real world query. In this case the query was of this form:

select * from (big inner query) foo order by a, b, c

The choice to use this query syntax was for programming brevity – it’s easier to rename the output columns from the big inner query using the outer query instead. Alas, though, the nasty version of this query took over 2.5 minutes to run on 53,000 record scans. The version without the outer select ran in 9/10th of a second on the same record space.

The EXPLAIN clearly showed that the outer select was doing a full table scan on the results instead of using the indices.

Unbelievable. I ran the exact same nasty query in Microsoft SQL Server 2000 and it performed as expectd – lightning fast execution. The execution plan showed the effective use of table indices and much smarter insertion of the sub-query’s grouping clauses.

MySQL needs quite a bit of real-world tuning to make it a believable enterprise database. You get what you pay for, right?

]]> By: ari http://www.mysqlperformanceblog.com/2006/08/31/derived-tables-and-views-performance/comment-page-1/#comment-127215 ari Fri, 18 May 2007 05:48:27 +0000 http://www.mysqlperformanceblog.com/2006/08/31/derived-tables-and-views-performance/#comment-127215 we are currently using mysql 5.037(27) it looks like when you create a view on a table and then use this view in query with a join or where statement with another table indexes from a view(first original table) are not used.Run the same query replacing view with a table it is based and result is in several times faster. we are currently using mysql 5.037(27)
it looks like when you create a view on a table and then use this view in query with a join or where statement with another table indexes
from a view(first original table) are not used.Run the same query replacing view with a table it is based and result is in several times faster.

]]> By: 派生表和视图的性能 at 周俭 Blog http://www.mysqlperformanceblog.com/2006/08/31/derived-tables-and-views-performance/comment-page-1/#comment-2585 派生表和视图的性能 at 周俭 Blog Sat, 16 Sep 2006 14:03:18 +0000 http://www.mysqlperformanceblog.com/2006/08/31/derived-tables-and-views-performance/#comment-2585 [...] 原文作者： Peter Zaitsev原文来源： http://www.mysqlperformanceblog.com/2006/08/31/derived-tables-and-views-performance译者：叶金荣（Email:），转载请注明译者和出处，并且不能用于商业用途，违者必究。 [...] [...] 原文作者： Peter Zaitsev原文来源： http://www.mysqlperformanceblog.com/2006/08/31/derived-tables-and-views-performance译者：叶金荣（Email:），转载请注明译者和出处，并且不能用于商业用途，违者必究。 [...]

]]> By: Martijn Tonies http://www.mysqlperformanceblog.com/2006/08/31/derived-tables-and-views-performance/comment-page-1/#comment-2220 Martijn Tonies Mon, 04 Sep 2006 10:01:58 +0000 http://www.mysqlperformanceblog.com/2006/08/31/derived-tables-and-views-performance/#comment-2220 Interesting, thanks for trying. -- Martijn Tonies Upscene Productions Interesting, thanks for trying.

–
Martijn Tonies
Upscene Productions

]]> By: peter http://www.mysqlperformanceblog.com/2006/08/31/derived-tables-and-views-performance/comment-page-1/#comment-2158 peter Fri, 01 Sep 2006 20:14:37 +0000 http://www.mysqlperformanceblog.com/2006/08/31/derived-tables-and-views-performance/#comment-2158 Martijn, First - you're right. There is no reason for derived tables to be materialized. It is design deficiency in MySQL 5.0. Speaking about Views with group by - good question. MySQL is currently able to execute via query merge only simple views, more complicated views as ones with group by require temporary table even if it is possible to avoid it. Hopefully it will be improved in the future: mysql> create view v1 as select count(*) cnt, k from test group by k; Query OK, 0 rows affected (0.03 sec) mysql> explain select * from v2 where k=7 limit 5; +----+-------------+------------+-------+---------------+------+---------+------+---------+-------------+ | id | select_type | table | type | possible_keys | key | key_len | ref | rows | Extra | +----+-------------+------------+-------+---------------+------+---------+------+---------+-------------+ | 1 | PRIMARY | <derived2> | ALL | NULL | NULL | NULL | NULL | 1638400 | Using where | | 2 | DERIVED | test | index | NULL | k | 772 | NULL | 1638400 | Using index | +----+-------------+------------+-------+---------------+------+---------+------+---------+-------------+ 2 rows in set (6.88 sec) As you see full temporary table is used, there is index on k but it only allows to do index scan instead of full table scan. Martijn,

First – you’re right. There is no reason for derived tables to be materialized. It is design deficiency in MySQL 5.0.

Speaking about Views with group by – good question. MySQL is currently able to execute via query merge only simple views, more complicated views as ones with group by require temporary table even if it is possible to avoid it. Hopefully it will be improved in the future:

mysql> create view v1 as select count(*) cnt, k from test group by k;
Query OK, 0 rows affected (0.03 sec)

mysql> explain select * from v2 where k=7 limit 5;
+—-+————-+————+——-+—————+——+———+——+———+————-+
| id | select_type | table | type | possible_keys | key | key_len | ref | rows | Extra |
+—-+————-+————+——-+—————+——+———+——+———+————-+
| 1 | PRIMARY | | ALL | NULL | NULL | NULL | NULL | 1638400 | Using where |
| 2 | DERIVED | test | index | NULL | k | 772 | NULL | 1638400 | Using index |
+—-+————-+————+——-+—————+——+———+——+———+————-+
2 rows in set (6.88 sec)

As you see full temporary table is used, there is index on k but it only allows to do index scan instead of full table scan.

]]>