修复损坏的表
即使用正确的类型创建了表并加上了合适的索引，工作也没有结束:还需要维护表和索引来确保它们都正常工作。维护表有三个主要的目的：找到并修复损坏的表，维护准确的索引统计信息,减少碎片。
表损坏(corruption)是很糟糕的事情。对于MyISAM存储引擎，表损坏通常是系统崩溃导致的。其他的引擎也会由于硬件问题、MySQL本身的缺陷或者操作系统的问题导致索引损坏。
损坏的索引会导致查询返回错误的结果或者莫须有的主键冲突等问题，严重时甚至还会导致数据库的崩溃。如果你遇到了古怪的问题——例如一些不应该发生的错误——可以尝试运行CHECK TABLE来检査是否发生了表损坏(注意有些存储引擎不支持该命令；有些引擎则支持以不同的选项来控制完全检查表的方式)。CHECK TABLE通常能够找出大多数的表和索引的错误。
mysql> ALTER TABLE innodb_tbl ENGINE =INNODB
此外，也可以使用一些存储引擎相关的离线工具，例如 myisamchk；或者将数据导出一份，然后再重新导入。不过，如果损坏的是系统区域，或者是表的“行数据”区域，而不是索引，那么上面的办法就没有用了。在这种情况下,可以从备份中恢复表，或者尝试从损坏的数据文件中尽可能地恢复数据。
如果 Innodb引擎的表出现了损坏，那么一定是发生了严重的错误，需要立刻调查一下原因。InnoDB一般不会出现损坏。InnodB的设计保证了它并不容易被损坏。如果发生损坏，一般要么是数据库的硬件问题例如内存或者磁盘问题(有可能)，要么是由于数据库管理员的错误例如在MySQL外部操作了数据文件(有可能)，抑或是InnodB本身的缺陷(不太可能)。常见的类似错误通常是由于尝试使用rsync备份InnodB导致的。不存在什么査询能够让InnoDB表损坏，也不用担心暗处有“陷阱”。如果某条査询导致InnodB数据的损坏,那一定是遇到了bug，而不是查询的问题。
如果遇到数据损坏，最重要的是找出是什么导致了损坏，而不只是简单地修复，否则很有可能还会不断地损坏。可以通过设置innodb_force_recovery参数进入InnoDB的强制恢复模式来修复数据，更多细节可以参考 MySQL手册。另外，还可以使用开源的InnoDB数据恢复工具箱( InnoDB Data Recovery Toolkit)直接从 InnoDB数据文件恢复出数据(下载地址:htp:/www.percona.com/software/mysql-innodb-data--recovery-tools/)。
