MySQL Performance: MySQL => which is fastest: a join or one big table?

Members

Help

Home

Home » Performance » MySQL » which is fastest: a join or one big table?

Show: Today's Messages :: Show Polls :: Message Navigator

which is fastest: a join or one big table? [message #1284]

Mon, 21 May 2007 22:43

bluem
Messages: 15
Registered: November 2006

Junior Member

I seem to be facing two possible scenarios. Which of these would offer the fastest SELECT?

Option 1) A master table that references 3 other tables via IDs. The nature of the SELECT will require that *every* row of the master table will be joined with a row from one or all of the 3 other tables. Any column in any affected table could be selectable, sortable or "countable" -- and so could benefit from an index; but will all the -joined- table indexes be usable?

Option 2) All data is in one big table already, with indexes on any selectable column, so virtually any query would be directly indexed; no joins are made. The number of columns has been multiplied greatly (and with much empty data) because I have essentially already joined everything myself and inserted the data into a big, fully indexed table. I wonder if this is better because MySQL need not create a temporary (joined) table.

Any advice is appreciated.

Report message to a moderator

Re: which is fastest: a join or one big table? [message #1286 is a reply to message #1284 ]

Tue, 22 May 2007 05:57

sterin
Messages: 323
Registered: March 2007
Location: Sweden

Senior Member

As usually the answer is: -"It depends!".

When you normalize your data into different tables you avoid storing duplicates.

And this essentially compresses the data in the database since the reference id (used in the join) is usually only a few bytes.

And this means that the DB size is less than if you store everything in one table.

If this means that it is the difference between that mysql can hold everything in RAM or that it has to read it from disk then you can benefit from it greatly.

But if on the other hand (due to your datas nature) it does not "compress" so much, then you won't benefit anything since as you said the DBMS has to performa a join instead.

Then you also have the issue with that if you have a large DB where essentially everything is stored on disk.
That disks are pretty fast reading sequentially but they are very slow reading randomly.

On one of the projects I worked on we had a large table (80GB, 200,000,000 rows).
And unless you knew that your select would use less than 5% percent of the rows in the table then you always forced it to use a table scan.

A table scan always took about 25 minutes (depending on load on system).
While a query that used indexes might easily take about 8 hours due to disk seek times.

So as you see there isn't a straight answer.
You will have to test it if you want to be sure.

Report message to a moderator

Re: which is fastest: a join or one big table? [message #1287 is a reply to message #1284 ]

Tue, 22 May 2007 12:19

bluem
Messages: 15
Registered: November 2006

Junior Member

Thanks for the reply. Very good to know.

If we assume that both scenarios take place in RAM -- will a join always be slower than reading from one table? I know, it probably "depends" Smile

Quote:

A table scan always took about 25 minutes (depending on load on system). While a query that used indexes might easily take about 8 hours due to disk seek times.

That's crazy - I thought indexes were supposed to speed up select queries? (How do you force a table scan?)

Final question: How do I know if mysql can hold everything in RAM? If I remember correctly, there are mysql settings for this.

Thanks.

Report message to a moderator

Re: which is fastest: a join or one big table? [message #1291 is a reply to message #1287 ]

Wed, 23 May 2007 04:04

sterin
Messages: 323
Registered: March 2007
Location: Sweden

Senior Member

bluem wrote on Tue, 22 May 2007 18:19

If we assume that both scenarios take place in RAM -- will a join always be slower than reading from one table?

Usually you don't have to think about it since if they are both in RAM then the amount of rows is small enough and since RAM is so very much faster than disks you don't really have the problem.

Quote:

A table scan always took about 25 minutes (depending on load on system). While a query that used indexes might easily take about 8 hours due to disk seek times.

bluem wrote on Tue, 22 May 2007 18:19

That's crazy - I thought indexes were supposed to speed up select queries? (How do you force a table scan?)

They are, but using an index means random access and if you are selecting just 1 row from a large table then it is a huge difference.
But if you are selecting all rows then using an index is just plain silly.
And somewhere between there you have a breaking point where it is more advantagous to just run a table scan.
For that perticular database that point was at about 1/20 of the rows.
And I forced it with a hint in the query but that perticular database was Oracle.

bluem wrote on Tue, 22 May 2007 18:19

Final question: How do I know if mysql can hold everything in RAM? If I remember correctly, there are mysql settings for this.

You can check the size of your DB and check how much RAM you got available on the server.
If you are running MyISAM table types then the important variable is key_buffer_size.
If you are running InnoDB then innnodb_buffer_pool_size is the important.
Read about them in the manual:
http://dev.mysql.com/doc/refman/5.1/en/server-system-variabl es.html
http://dev.mysql.com/doc/refman/5.1/en/innodb-parameters.htm l

Report message to a moderator

Previous Topic:	Index Question
Next Topic:	MySQL Optimal Settings

Goto Forum:

-=] Back to Top [=-

[ Generate printable PDF ] [ Syndicate this forum (XML) ] [

]

Current Time: Tue Jan 6 03:10:32 EST 2009

Total time taken to generate the page: 0.00547 seconds

.:: Contact :: Home :: MySQL Support by Percona.com ::.