There is simply too many systems where the combination of poor design and the current limitations (or weakness) of MySQL leads to these types of issues.

We would all do better to promote the Best Practices of avoiding these types of issues in the first place.

http://ronaldbradford.com
MySQL Expert
MySQL Community Member of the Year 2009

I read it as “Perfect people never need Innodb File Per Table” which is correct, however there are not much of these perfect people around.

It is so frequent to see mistakes causing table space to run away and confuse all space on partition and whatever dumping tools you use dumping hundreds of gigs of highly indexes data is not fun.

Same applies to filesystem – many people just have what they have – running MySQL in hosted envinronment or having OS which does not support smart filesystems out of the box.

Though indeed if you have many thousands of small tables file per table is quite likely to be slower.

1. alter table
2. LVM/Filesystem snapshot backups.

LVM backups being directly related to alter table. Without using file per table if I alter a huge table now my backups have to deal with processing what is essentially wasted space.

When online backups are better and online alter table is the norm it may make sense to ditch file per table. Until then I’m sticking with it.

the ‘annoying’ bit wasn’t personal :) It was applied to much wider group of people!

and FUD stands for ‘fear, uncertainty, doubt’. in this case, against large files! :)

Anyway, I understand that one can come up with ’situations’. Maybe thats unfortunate in situations with ‘poor users’. Still, if you do ALTER once, you may need to do it twice. If you have logging data, there may be more logging data, etc.

Oh, and in my practice, I’m very much used to reimaging servers. It is part of regular staging process :-)

In this case, being able to recover the space in a hurry is a nice to have ;) It makes backups easier, etc.

1st, Three big cheers for calling me annoying, this is the first time anyone has taken my technical writings to the personal level. I don’t take it hard though.

2nd: FUD? As in MS vs. Linux? FUD against who?

Now, let’s describe some real scenario, and I agree with the example provided by Bill Karwin on 1st comment.
You have a database in one single tablespace. There is one very large table which takes 40% of disk space, the rest of the tables take 10%. Total 50% disk space.
Aha, now there’s a need for some ALTER TABLE on the big table. ALTER TABLE requires space for building the new table. Space taken from the file system. There goes another 40% of disk space, and all of the sudden you are at 90% capacity.

Is this space I’m going to utilize later on? No. I just happened to require it for a one time operation, it’s not like my data will grow into it in the next couple of days.

I’ve seen poor users who didn’t have innodb-file-per-table, who didn’t know it exists (no one told them), who got their production systems’s disk full or almost full, and who had to migrate to a slave or otherwise recover from backup to regain disk space. Yes, they needed the disk space!

“Oh, wait, this was given as an argument:… …Right”
English is not my mother tongue. I meant to say you don’t need access for MySQL as you would need in order to access SHOW TABLE STATUS etc.

Programmer: “We’re running out of disk space, that’s why our uploads directory can’t take any more files.”

Manager: “We have to get our website back online in the next few minutes or our business is sunk. Archive some of the older data and delete it out of the database.”

Programmer (after some minutes): “Done. But the filesystem is still full and we’re still getting errors.”

Manager: “WTF?!?”

You try telling that manager that InnoDB will reuse the space for new data gradually. That’s not going to help make space on the filesystem in the next few minutes — or ever.