MySQL: Many tables or many databases?

Question

For a project we having a bunch of data that always have the same structure and is not linked together. There are two approaches to save the data:

• Creating a n

Answer 1

If you don't want one set of tables with poolID poolname as TheTXI suggested, use separate databases rather than multiple tables that all do the same thing.

That way, you restrict the variation between the accessing of different pools to the initial "use database" statement, you won't have to recode your SELECTs each time, or have dynamic sql.

The other advantages of this approach are:

• Easy backup/restore
• Easy start/stop of a database instance.

Disadvantages are:

• a little bit more admin work, but not much.

I don't know what your application is, but really really think carefully before creating all of the tables in one database. That way madness lies.

Edit: If performance is the only thing that concerns you, you need to measure it. Take a representative set of queries and measure their performance.

Edit 2: The difference in performance for a single query between the many tables/many databases model will be neglible. If you have one database, you can tune the hell out of it. If you have many databases, you can tune the hell out of all of them.

My (our? - can't speak for anyone else) point is that, for well tuned database(s), there will be practically no difference in performance between the three options (poolid in table, multiple tables, multiple databases), so you can pick the option which is easiest for you, in the short AND long term.

For me, the best option is still one database with poolId, as TheTXI suggested, then multiple databases, depending upon your (mostly administration) needs. If you need to know exactly what the difference in performance is between two options, we can't give you that answer. You need to set it up and test it.

With multiple databases, it becomes easy to throw hardware at it to improve performance.

Answer 2

I don't know mysql very well, but I think I'll have to give the standard performance answer -- "It depends".

Some thoughts (dealing only with performance/maintenance, not database design):

• Creating a new database means a separate file (or files) in the file system. These files could then be put on different filesystems if performance of one needs to be separate from the others, etc.
• A new database will probably handle caching differently; eg. All tables in one DB is going to mean a shared cache for the DB, whereas splitting the tables into separate databases means each database can have a separate cache [obviously all databases will share the same physical memory for cache, but there may be a limit per database, etc].
• Related to the separate files, this means that if one of your datasets becomes more important than the others, it can easily be pulled off to a new server.
• Separating the databases has an added benefit of allowing you to deploy updates one-at-a-time more easily than with the single database.

However, to contrast, having multiple databases means the server will probably be using more memory (since it has multiple caches). I'm sure there are more "cons" for the multi-database approach, but I am drawing a blank now.

So I suppose I would recommend the multi-database approach. Obviously this is only with the understanding that there may very well be a better "database-designy" way of handling whatever you are actually doing.

Answer 3

In the situation you describe, experience has led me to believe that you'll find the separate databases to be faster when you have a large number of pools.

There's a really important general principle to observe here, though: Don't think about how fast it'll be, profile it.