Re^3: Speed of MySQL DBs

Given the added detail, I agree that one big table is not as good as a bunch of smaller tables. As to whether a lot of tables is better or worse than a set of distinct databases ... well, there is a whole chapter (7) in the MySQL manual about optimization. Have you looked at that yet?

I don't know off hand whether mysql's data files are "one per table" or "one per database" -- and I'm not sure if that even makes a difference for performance.

If you aren't familiar with the science and art of creating indexes on fields that are often used in the "where" clause, maybe it would be more effective to study that before trying "separate databases vs. separate tables in one database". Indexes are pretty easy to add to a running database, and can have a dramatic effect on query response time. (UPDATE: Then again, if you have other good reasons for using separate databases, go ahead -- I doubt it would damage performance at all, and might even help.)

Comment on Re^3: Speed of MySQL DBs

Replies are listed 'Best First'.
Re^4: Speed of MySQL DBs by eric256 (Parson) on Feb 06, 2006 at 18:17 UTC
You realy think multiple tables is better? I'm realy curious as to why and when this would be beneficial. I read several parts of the MySQL documentation on Optimizations but I never realy saw a conclusive line of when this would be good to do. I would have thought that a well indexed single table would always be better then multiple tables. ___________ Eric Hodges	[reply]
Re^5: Speed of MySQL DBs by graff (Chancellor) on Feb 07, 2006 at 01:20 UTC
Based on rsiedl's description of the setup, it sounded like there was already a rational basis for segmenting the data into distinct tables, and the usage pattern for the data didn't seem to motivate full integration into a single huge table (rows fall into large independent sets, and queries never need to span across sets). I'll confess that I'm no jedi when it comes to optimizing an RDB through careful crafting of table layout, query construction and indexing. This probably explains why I can imagine situations where the conditions on an oft-needed query might not lend themselves easily to effective indexing, and reducing the size of a full-table scan would be worthwhile.	[reply]