Comments on: MySQL VIEW as performance troublemaker

By: Jesse Price

Jesse Price — Wed, 09 Sep 2009 12:31:38 +0000

Hmm, it appears that using views which could be a quicker way to make db calls especially in joins and subqueries… never realized how bad the performance is by using them. I wonder if this performance issue also occurs when creating triggers and stored procedures.

By: Baron Schwartz

Baron Schwartz — Mon, 24 Aug 2009 17:55:19 +0000

Blakkky, you should learn the execution plan differences between joins and correlated subqueries.

By: Blakkky

Blakkky — Mon, 24 Aug 2009 16:19:12 +0000

LOL, very useless article!

Author try to compare two uncompirable things!
Look here: Simple select is slower then view-select (ROFL):
==================================================
Simple select:
mysql> select count(*) from (select * from comments where user_id in (select user_id from comments where user_id = 5 group by user_id)) t2;
+———-+
| count(*) |
+———-+
| 100 |
+———-+
1 row in set (3.71 sec)

And from VIEW (CREATE VIEW user_counts AS SELECT * FROM comments):
mysql> select count(*) from user_counts where user_id = 5;
+———-+
| count(*) |
+———-+
| 100 |
+———-+
1 row in set (0.00 sec)
==================================================

Author’s problem NOT IN VIEW at all, but in using a view for non-view-based operations!

VIEW – mechanism to make a pseudo-tables for database users (for example, to make four different client lists based on three tables (account, client, client-address) tables: client’s names list, client’s address list, client’s detail info list. On this lists client-side-software maps grids, combo-boxes and other.

In author’s example, VIEW works slowly ONLY AND ONLY BECOUSE autor use a GROUP BY statement in VIEW!

PS: sorry for my english, i’m not from english-speaking country

By: Enabling Implicit Cast From Integer To Boolean in PostgreSQL | chrisspenblog

Tue, 18 Aug 2009 17:36:13 +0000

[...] complicated queries, and I’m running into a few obnoxious limitations, mostly involving known view performance problems. I’ve decided to start testing the waters in PostgreSQL, so I tried importing my data into PG [...]

By: View vs. Join - php.de

View vs. Join - php.de — Tue, 17 Mar 2009 06:58:21 +0000

[...] @dsmcg: Meinst Du den "Sonderfall", dass Du immer (oder zumindest sehr oft) das exakt selbe JOIN ohne veränderliche Parameter ausführst? Dann könnte Dir ein View zwei Vorteile bieten: Du musst Dich nicht auf den Query Cache verlassen, da der Query Plan getrennt und persistent abgespeichert werden könnte. Und Du verbirgst die eigentlichen Datenquellen vor der Applikation. Wenn Du Dich also entschließen solltest, dass die Datenstruktur zu kompliziert ist und Du den Aufbau der Datenbank ändern willst, musst Du die Applikation nicht anpassen. Soviel zur Theorie… in der Praxis sieht das gleich noch mal anders aus. Bei handgepflegten, handoptimierten (Oracle-)Datenbanken kann das richtig Klasse sein. Wenn Du den Datenbankserver einfach machen lässt, kannst Du schnell unerwartete Falschhälse schaffen, siehe zum Beispiel MySQL VIEW as performance troublemaker | MySQL Performance Blog [...]

By: dendie

dendie — Tue, 24 Feb 2009 15:32:10 +0000

nice articel… thanks for your backmarking…

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..