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

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

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

http://www.zblmw.com

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?

–
Martijn Tonies
Upscene Productions

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.

eg: GROUP BY or have a SUM in it.

Now, do a “select * from view where summed_column = 50″ or something.

Will this be re-written? And if so, what IS the final result of the re-written query?

Besides, why DO derived tables get materialized anyway? The optimizer is free to re-write queries including these as well, right?

–
Martijn Tonies
Upscene Productions

The difference is not inheriting indexes but as I wrote different method of execution - Views are executed (in this case) by query rewriting, so effectively query becomes same as on base table. Inline views/derived tables however can’t do it they always have to materialize table.

Creating view you can also force it to use TEMPTABLE for query execution. See

http://dev.mysql.com/doc/refman/5.0/en/create-view.html

Regarding behavior in real cases - this is simplification based on real production cases.

Note: It applies to subselects in FROM clause only. Other kind of subselects is very different story.

Do you get similar results in less contrived (more realistic) scenarios?