Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

Performance of MySQL View is Worse than that of Underlying Query [duplicate]

I have a MySQL view defined using the below (JOIN statements omitted for brevity).

CREATE VIEW vw_example AS 
SELECT a, b, c FROM x, y, z

Over many repetitions SELECT a, b, c FROM x, y, z is 5 times faster than SELECT a, b, c FROM vw_example.

I'm looking to understand why this is and how to bring the SELECT FROM vw_example performance inline with the underlying SELECT FROM x, y, z.

like image 932
Jobu Avatar asked Mar 30 '13 18:03

Jobu


3 Answers

Although you don't show a DISTINCT in your example query, I recently discovered this to be the one single distinguishing factor in the performance difference between a query run directly, vs run as a view.

With SELECT DISTINCT on my query doing an INNER JOIN on a 726,000 row table and a 303,000 row table, joining ON 3 columns for which each table has an index, the direct query is running about 0.15-0.16s duration. When I use the VIEW created with the same query (and nothing else) the duration is about 142-145s or about 10^3 times as long.

Removing DISTINCT reduced both the query itself and the view it is based on to 0.016s--there is virtually no difference at all.

I can't help with understanding why--only with recognizing one cause in one particular case.

like image 63
Kirk Fleming Avatar answered Nov 07 '22 20:11

Kirk Fleming


I am not sure, but maybe mysql is using tmp tables much better for one of the queries. Please adjust these settings and then try again:

tmp_table_size   100M
max_heap_table_size 128M
query_cache_limit  350M
query_cache_size 300M

Use set global before them so that you can set them on the fly, hope this might just work. If not then you might need to look into re writing the query.

like image 43
Masood Alam Avatar answered Nov 07 '22 19:11

Masood Alam


It's hard to be precise - the best way to investigate is to run EXPLAIN on both flavours of the query.

However, my suspicion is that the query cache is at the heart of this - re-running the same query will seed the query cache, and unless the underlying data changes, or the cache gets flushed, you're likely to benefit from the caching.

You'd expect to get that benefit when hitting the view, too, but caching is non-deterministic, and my guess is that, somehow, your queries against the view aren't benefiting from the caching.

If the EXPLAINs are identical, that would be the best explanation...

like image 34
Neville Kuyt Avatar answered Nov 07 '22 19:11

Neville Kuyt