views:

127

answers:

3

I have some demanding mysql queries that have to select same frequently updated datasets from 5-7 mysql tables. 'Select' operation would be a bit more than CUD.

I am thinking of creating a table or materialized view to gather all demanding columns from other tables, so as to reduce overall query times to different tables and thus increase performance.

If I create that table, I may need to do extra insert / update / delete operation each time other tables updated.

if I create materialized view, I am worrying if the performance can be greatly improved. Because data from other tables are changing very frequently. Most likely, the view may need to be created first everytime before selecting it.

Any ideas? e.g. how to cache? other extra measures I can do?

+2  A: 

I am thinking of creating a table or view to gather all demanding columns from other tables, so as to increase performance.
Most likely, the view may need to be created first everytime before selecting it.

Views are nothing but query. So doesn't matter whether you make query to select from view or just execute plain sql - the performance will be the same.

how to cache

Caching is very complex and specific question. So there is no panacea and to make decision more details should be provided.

zerkms
So if I have many more 'select' than CUD, then creating a new table is more appropriate for performance? otherwise, using view to combine tables is fine?
Carson
nope. it's unknown how to increase performance in your particular case while we don't know the details: what kind of data stored, the kind of queries (which is the most: insert/update/delete/select), the kind of selects (the typical queries), selects/modifications ratio, number of rows now, data grow speed, current and expected load, etc etc
zerkms
Is the query slow? If so, is it fully indexed?
Seun Osewa
A: 

It seems to me that you are thinking along the lines of the "materialized view" concept.

Mysql does not provide an implementation of this, though it can be simulated with some more or less sophistication (I do something similar to the later in Postgresql - it's handy for complex non-parametrized queries that are frequently used in reports, and for which is tolerable to have not totally up-to-date data).

leonbloy
yes. I mean materialized view. My data is kind of always up-to-date. I have non-parametrized query that select data through 5-7 tables. so in my case, both creating materialized view and an extra table don't seem to be viable options for better performance?
Carson
A materialized view is always viable for better performance. But, if you really need strictly up-to-date data (i.e. the mat. view must reflect exactly the "true" view) you'd need to do extra work with triggers, as in my first link. Perhaps some rethinking of your db schema (perhaps even some de-normalization) might be preferable.
leonbloy
A: 

As said below, there is no panacea for increasing performance. And, unlike what was said above, indexes are not the most important thing for DB performance - having a correctly set up database is. As the database gets larger DB configuration can come to dominate performance. Most important in this is having an appropriately configured disk subsystem since large databases are always limited in their performance by how fast data can be gotten to/from disk.

As for your specific questions, faking a materialized view via queries may or may not help you. It will likely slow down your insert and update performance while possibly increasing your select performance. Creating the "view" on demand when needed will do absolutely nothing for you as you're having to run your slow query to create it anyways. Since MySQL doesn't directly support materializing views a standard view will do nothing for you.

Without more details better help is impossible to give.

Donnie