Comments on: MySQL VIEW as performance troublemaker

By: Dancing Mammoth :: Blog Archive :: Derived Attributes with UNION

Dancing Mammoth :: Blog Archive :: Derived Attributes with UNION — Sun, 10 Aug 2008 16:14:26 +0000

[...] MySQL 5.0 or above, you won’t be able to mitigate this problem by using a VIEW. MySQL is not very good at optimizing views. If there is not a one-to-one relationship between the rows of your view and the rows of the [...]

By: Dave

Dave — Sun, 13 Jul 2008 01:15:08 +0000

This post makes it clear that indexes will not be used for views that use temporary tables. For views that do not use temporary tables, will ‘joining’ or ‘whereing’ on a column that is indexed in the underlying table use that index?

By: Bimal Poudel

Bimal Poudel — Wed, 30 Apr 2008 11:23:03 +0000

Views meant to hide the complexities in the user’s side. This helps you to shorten your query. Optimization is to be done from the MySQL server itself. But have you ever heard of something like indexing a view? Something else? As a developer, performance too matters.

By: John

John — Thu, 10 Apr 2008 13:50:20 +0000

Ascanio and others: Try using Stored Procedure, for this example.

DELIMITER $$
DROP PROCEDURE IF EXISTS `test2`.`user_count` $$
CREATE DEFINER=`root`@`localhost` PROCEDURE `user_count`(param1 int)
BEGIN
SELECT count(*) FROM comments WHERE user_id=param1;
END $$
DELIMITER ;

Run the above code
then CALL user_count(5); It will run SELECT count(*) FROM comments WHERE user_id=5; and just as fast as the straight select (from my testing less than 0.001 milisecond difference, sometimes the CALL was faster, but thats just due to random flux you might notice a difference if you were making thousands of calls a second..

By: peter

peter — Wed, 19 Mar 2008 03:44:31 +0000

Not in 5.1 at least. 6.0 have some optimizations which would affect views but I’m not sure if there are general fixes.

By: Geoff

Geoff — Wed, 19 Mar 2008 03:25:06 +0000

Have MySQL views improved at all - for any version?

By: Ascanio

Ascanio — Sat, 09 Feb 2008 20:53:50 +0000

I’ve been working with MySQL Views since release 5 was first made available.
It took me and my team about 2 months of testing to understand that it is just too soon to use Views.

What we did as a solution was to create an extra layer between PHP and MySQL (written in PHP). Hardcoding the complex queries in functions, with our own caching logic. This made it for us, for now.

By: peter

peter — Tue, 22 Jan 2008 11:47:24 +0000

How would you use views to cache queries in MySQL ?

MySQL does not have materialized views so whenever you access view it will be always reevaluated.

By: Serban

Serban — Sat, 12 Jan 2008 10:12:11 +0000

i see VIEWS like a good alternative to caching some of the queries. Example: you have a site, with a `categories` menu (parent->childs) that are conditioned to appear in the menu by the number of `products` they reffer to. Every time a user loads a page you load that menu. If you have a large database, you don’t want to execute each time that menu (query), so you only SELECT the view. i think this is a primary use of VIEWS besides caching reports that don’t contain indexes but full values. please correct me if i’m wrong.

By: Bill Ford

Bill Ford — Tue, 20 Nov 2007 16:48:29 +0000

If I have a view used to join data (via a UNION select) stored in separate tables, then use a where clause when selecting from the view, is that a case where MySQL would be inefficient? I don’t want it to create a temporary table of ALL the data in ALL the tables, I really was hoping for more of a macro-expand kind of thing.