1. Add innodb_file_per_table to my.cnf
2. Startup mysql and optimize all tables
3. mysqldump all DBs
4. Stop mysql
5. delete ibdata1 and logfiles
6. Startup mysql and import from mysqldump

This should take care of all fragmentation with innodb tables and this will create a new ibdata1 file on startup

Thanks again for everything!

innodb_file_per_table is a good way to go to ease space management.

Sorry for the newbie questions, but I have a few more.

This actually just worked. I add the line to mysqld within my.cnf. I then optimized the fragmented table and the free data went away. However, I did not need to recreate the table unless optimize took care of this already? Also is having innodb_file_per_table the better way to go? Or should I disable this once my fragmentation is repaired?

Thanks again!

Note however you will need to recreate tables to start using it. And you main tablespace ibdata1 will never shrink – typically you would reload database when you start using innodb_file_per_table.

OPTIMIZE TABLE will free disk space if innodb_file_per_table is used. Otherwise it will normally increase free space in innodb tablespace by having pages being more full as well as make table primary key index less fragmented – so full table scan and PK ranges will be faster.

For Innodb optimize table does not sort indexes (as it does for MyISAM) so the benefit is less.

It really depends. In some cases when there is prevailing access method which is different from physical row layout it can make a huge difference. In other cases one may not know prevailing access or may not have time to run alter table order by regularly. Running ALTER TABLE … ORDER BY … is often much slower than OPTIMIZE TABLE.

Good catch though it does not have anything to do with table fragmentation. Simply if you’re querying number of rows in table for Innodb it performs estimation – this estimation requires several random dives in the clustered index, which causes IO for large table sizes.