Re: Different ibdata files for every database
1. stop mysql
2. find the exact size, in bytes, of ibdata1
3. divide by 1048576 (1MB)
4. edit my.cnf (my.ini); use that number in ibdata1:#####M,ibdata2:10M:autoextend
5. start mysql
But why?
There is virtually no need for ibdata2 (etc) these days.
As for ibdata1:10M;ibdata2:10M;ibdata3:10M -- that tells InnoDB how to lay out 30MB of space on disk. InnoDB then sees one uniform tablespace of 30MB. It will scatter a 12MB table throughout the 30MB in whatever way it feels like. You cannot predict which 10M chunk(s) it will be in.
Look at it this way... That notation was quite useful in the "old days" when operating systems could not handle a single file bigger than 2GB (or maybe 4GB). InnoDB had grander plans -- tables bigger than 2GB. So, the solution was to hide the OS's inadequacies behind this notation.
For the last decade, the rational approach has been simply:
ibdata1:10M:autoextend
and let the file grow as needed.
Recently, a better approach came about -- innodb_file_per_table. This allows has each table owning its own tablespace, and the setting is not needed. However, InnoDB needs some space in the common tablespace (ibdata1), so the 10M:autoextend is still useful.
For those who are transitioning from the older methods to file_per_table, alas, there is no easy migration strategy. One has to dump the tables (mysqldump), drop ibdata*, change my.cnf, restart, and reload.
Note: No tablespace can ever be shrunken. ibdata1 can be restarted, as above. file_per_table can be restarted, but only by DROPping the table (possibly as part of an ALTER...ENGINE=).