维护表有三个主要的目的：
1、找到并修复损坏的表。
对于MyISAM存储引擎来说，表损坏通常是系统崩溃导致的。其他的引擎也会由于硬件的问题，MySQL本身的缺陷或者操作系统的问题导致索引的损坏。
损坏的索引，会导致查询返回错误的结果或者莫须有的主键冲突等问题，严重时还会导致数据库崩溃。
这类情况，可以尝试check table来检查是否发生了表损坏，有些存储引擎不支持这个命令。
可以使用repair table 来修复损坏的表，但同样不是所有引擎都支持该命令。
如果引擎不支持，可以使用alter操作重建表，或者将数据导出然后再重新导入。
InnoDB一般不会损坏，如果发生损坏，一般要么是数据库硬件问题，例如内存或者磁盘问题，要么就是数据库管理员操作导致。
常见的错误是由于尝试使用rsync备份InnoDB导致的。
如果是某条查询导致的，那一定是遇到了bug,而不是查询的问题。
2、维护准确的索引统计信息。
MySQL的查询优化器会通过2个API来了解存储引擎的索引值的分布信息，以决定如何使用索引。
第一个API是records_in_range(),通过向存储引擎传入两个边界值获取在这个范围大概有多少条记录。
对于某些引擎，该接口返回精确值，比方说MyISAM;对于InnoDB则是一个估算的值。
第二个API是info(),该接口返回各种类型的数据，包括索引的基数。
当返回信息不准确的时候，优化器会使用索引统计信息来估算扫描行数。如果表没有统计信息，或者统计信息不准确，优化器很可能做出错误的决定。
可以运行analyze table 来重新生成统计信息。
Memory引擎不存储索引统计信息
MyISAM将索引统计信息存储在磁盘中，analyze table 需要进行一次全表扫描，整个过程需要锁表。
MySQL5.5以后，InnoDB也不在磁盘存储索引统计信息，而是通过随机的索引访问来进行评估并存储在内存中。
使用show index from 命令可以察看索引基数（Cardinality）
InnoDB会在首次打开表，或者执行analyze table,或者表大小发生变化超过1/16或show table status,或show index时候都会计算索引的统计信息,如果服务器有大量的数据，这会是个严重的问题，只要show index查看索引统计信息就一定会触发统计信息更新，可以关闭
innodb_stats_on_metadata参数来关闭。
一旦关闭自动更新，那么需要周期性的使用analyze table 来手动更新，否则问题大了。
3、减少索引和数据碎片
B-Tree索引可能会碎片化，这会降低查询效率。碎片化的索引可能会以很差或者无序的方式存储在磁盘上。
可以通过optimize table 或者导出再导入的方式来重新整理数据。
对于不支持optimize table 的存储引擎，可以通过一个不做任何操作的alter table来重建表。
alter table <table> engine=<engine>;
也可以先删除索引，重建表，最后重新创建索引来实现。
索引的介绍就先到这里了，明天进入查询性能优化部分！
本文出自 “phper-每天一点点~” 博客，请务必保留此出处http://janephp.blog.51cto.com/4439680/1314057