Schema的优化和索引 - 索引和表的维护

核心提示：当你已经创建了一张表，有合适的数据类型，Schema的优化和索引 - 索引和表的维护，并添加了索引之后，其实你的工作还并没有结束：你还需要维护你的表和索引使它们工作的更好，或者如果它们过期了，优化器可能就会有个比较差的决定，表的维护有三个主要的目标：发现和解决表的损坏，维护准确的索引统计

当你已经创建了一张表，有合适的数据类型，并添加了索引之后，其实你的工作还并没有结束：你还需要维护你的表和索引使它们工作的更好。表的维护有三个主要的目标：发现和解决表的损坏，维护准确的索引统计，并且要降低存储碎片。

找到和修复损坏的表

最差的事情莫过于表已经损坏了。对于MyISAM，大部分是由于当机所造成的。然而，所有的存储引擎都会由于硬件问题或者MySQL内部BUG再或者操作系统的原因导致索引的损坏。

损坏的索引能导致查询返回不正确的结果，当没有重复值出现却抛出重复键值的错误，或者导致查询死锁和当机。如果你碰到了奇怪的行为-比如一个你意想不到的错误，就CHECK TABLE来查看表是否损坏。CHECK TABLE一般可以检查大部分表和索引的损坏。

你可以使用REPAIR TABLE来修复。但是并不是所有的引擎都支持这个命令。这样你可以使用ALTER命令，比如修改和表相同的存储引擎。

mysql> ALTER TABLE innodb_tbl ENGINE=INNODB;

你也可以使用离线的针对存储引擎的修复工具。比如myisamchk或者删除数据再重新加载。然而，如果换坏是发生在系统中，或者在表中的“行数据”取代了索引，你就无能为力了。这种情况下，你只能从备份中恢复表或者从损坏的文件中恢复数据。以后会详细说到。

更新索引的统计

MySQL的查询优化器使用两个API从存储引擎中得知当决定怎样使用索引的时候，索引是怎样分布的。第一个是records_in_range调用。它传入终结点范围并且返回了范围的记录的值。第二个就是info(),它返回了不同类型的数据，包括了索引的基数（对于每个键值有多少数据）。

当存储引擎并没有提供给优化器关于查询行数的准确信息，这个优化器就会使用索引的统计信息。这个信息你可以使用ANALYZE TABLE来估计下行数。MySQL的优化器是基于成本的，并且最主要的消耗因素就是这个查询要访问多少数据。如果这个统计信息没有生成，或者如果它们过期了，优化器可能就会有个比较差的决定。方案就是使用ANALYZE TABLE来生成统计数据。