MySQL Reference Manual :: 13.5.2.5 OPTIMIZE TABLE Syntax

OPTIMIZE [LOCAL | NO_WRITE_TO_BINLOG] TABLE tbl_name [, tbl_name] ...

OPTIMIZE TABLE should be used if you have deleted a large part of a table or if you have made many changes to a table with variable-length rows (tables that have VARCHAR, BLOB, or TEXT columns). Deleted records are maintained in a linked list and subsequent INSERT operations reuse old record positions. You can use OPTIMIZE TABLE to reclaim the unused space and to defragment the data file.

In most setups, you need not run OPTIMIZE TABLE at all. Even if you do a lot of updates to variable-length rows, it's not likely that you need to do this more than once a week or month and only on certain tables.

For the moment, OPTIMIZE TABLE works only on MyISAM, BDB and InnoDB tables.

For MyISAM tables, OPTIMIZE TABLE works as follows:

For BDB tables, OPTIMIZE TABLE currently is mapped to ANALYZE TABLE. That was also the case for InnoDB tables before MySQL 4.1.3; starting from this version it is mapped to ALTER TABLE, which rebuilds the table. Rebuilding updates index statistics and frees unused space in the clustered index. See Section 13.5.2.1, “ANALYZE TABLE Syntax”.

You can get OPTIMIZE TABLE to work on other table types by starting mysqld with the --skip-new or --safe-mode option; in this case, OPTIMIZE TABLE is just mapped to ALTER TABLE.

Note that MySQL locks the table during the time OPTIMIZE TABLE is running.

Before MySQL 4.1.1, OPTIMIZE TABLE statements are not written to the binary log. As of MySQL 4.1.1, they are written to the binary log unless the optional NO_WRITE_TO_BINLOG keyword(or its alias LOCAL) is used. This has been done so that OPTIMIZE TABLE commands used on a MySQL server acting as a replication master will be replicated by default to the replication slave.