3 ms·
That's pretty silly, as any serious installation is generally using innodb_file_per_table, and thus not really subject to this problem. Nonetheless, it's a lot
by jeremycole 13y ago
That's pretty silly, as any serious installation is generally using innodb_file_per_table, and thus not really subject to this problem.
Nonetheless, it's a lot more complicated than it would seem to "just reclaim the space".
- samcrawford 13y agoI disagree that any serious installation is using innodb_file_per_table. It does have downsides. In our use case we're making very heavy usage of table partitioning (over 500 partitions for some of our very large tables). Because each partition is effectively another table under the covers, if we were to use innodb_file_per_table then we'd have tens of thousands of files. This means a lot more file handles being opened/closed (as well as the obvious ulimit gotchas for the uninitiated). This noticeably hampered query performance when seeking data from random partitions.
- dmourati 13y agoI've managed many non-trivial MySQL installations that didn't set file_per_table. I agree it is a step towards fixing the problem but can create potentially other issues. Current shop is not running file_per_table, and has little reason to do so at ~30GB database file size. Still, dropping the table and not reclaiming any space was a rude awakening. Combine that the fact that storage was an AWS EBS sized pretty close to its limit (50GB). I could not perform two iterations of a test import without first rm'img the file. Lame.