很难说Optimize Table到底能不能提高系统运行效率，但是有一点是肯定的：它能够帮我们回收更多的空间、减少“碎片” （defragment）。

1. 回收空间 Defragment

在InnoDB的维护过程中，我们总会遇到磁盘耗尽、或者InnoDB Tablespaces用完的情况。这时候，在考虑扩容等方案之前，最好先使用Optimize Table试试。如果你的表大字段（Text Blob Varchar），并且更新、删除较频繁的话，Optimize之后可能会腾出大量的空间。

以前没有遇到InnoDB文件损坏的情况，特此记录。从日志来看，损坏的应该是一个索引页，导致对应的数据表无法访问，也无法获取对应数据表中的数据，尝试check optimize也无法修复。最后设置innodb_force_recovery=1后启动数据库后，能够导出全部数据。

1. 故障

nnoDB和MyISAM是在使用MySQL最常用的两个表类型，各有优缺点，视具体应用而定。基本的差别为：MyISAM类型不支持事务处理等 高级处理，而InnoDB类型支持。MyISAM类型的表强调的是性能，其执行数度比InnoDB类型更快，但是不提供事务支持，而InnoDB提供事务 支持已经外部键等高级数据库功能。

译这个文章的目的：
最近经常被问起Innodb是如何使用内存的。该问题早已被原MySQL公司的Vadim论证过。我这里译一下他的文章供大家参考。
开始：
这里有许多关于Innodb如何使用内存的问题。我这里将会以innodb启动时的分配情况做一个解释。一些重要的概念：
NBLOCKS＝Innodb_buffer_pool有多个页 (block)＝innodb_buffer_pool_size/16384(16k)
OS_THREADS= if ( innodb_buffer_pool_size >= 1000Mb) = 50000

Innodb的表空间是在配置文件中定义（说是表空间有时觉的有点羞愧，和Oracle比真的差太远了），这里简单列一下表空间里的基本概念及表的分配情况。
表空间是在配置文件中定义的几个文件简单的耦合起来，在使用中互不可少（少一个就面临DB完蛋的危险）。对于共享表空间无法确定表所在的表空间上。

Innodb是一个多版本的存储引擎，它可以把旧的行信息存到表空间中。这些旧的行信息存储到Innodb称为的回滚段的表空间中。

Innodb为实现多版本，Innodb在每一行添加了三个列。一个6字节的DB_TRX_ID字段用来表示事务的Insert或是Update操作，对于Delete操作实际上也并不在直接删除，只是用一个Bit位去标识行被删除。另外，每行包括7字节的DB_ROLL_PTR字段，称为回滚指针（roll pointer）。这个回滚指针指向回滚段（undo segment）中的回滚记录。如果行被更新，那么回滚段中记录的信息足以使update操作加到update操作之间。最后还有一个6字节的 DB_ROW_ID字段，该字段包含新行的Row Id，这个字段只在Insert操作时单纯的增加。DB_ROW_ID是需要一个互诉锁的才能产生。Innodb产生的clustered index包括Row ID.从另一方面来说，除了Clustered Index索引外，其它的索引不会包含Row Id.