如何在MySQL中维护索引和数据表？很多新手对此不是很清楚，为了帮助大家解决这个难题，下面小编将为大家详细讲解，有这方面需求的人可以来学习下，希望你能有所收获。
查找和修复数据表冲突
数据表最糟糕的事情就是发生冲突。使用MyISAM存储引擎时，通常因为崩溃导致冲突。然而，当存在硬件故障、MySQL内部Bug或操作系统Bug时，所有的存储引擎都可能遭受索引冲突。
冲突的索引可能导致查询返回错误的结果，在没有重复值时的重复索引错误增加，甚至可能导致全表扫描或崩溃。如果你遇到过偶发的事件，例如一个你认为不会发生的错误，这个时候运行CHECK TABLE命令去检测数据表是否有冲突（注意有些数据库引擎不支持这个命令，有些则支持多种选项参数去指定如何检测表）。通常，CHECK TABLE命令会捕获大部分的数据表和索引错误。
你可以通过REPAIR TABLE命令修复数据表错误，但是也不是全部存储引擎都支持这个命令。这个时候你需要执行一个“没有操作”的ALTER语句，例如将一个数据表的引擎修改为和当前的引擎一样，例如可以对InnoDB的数据表执行下面的语句：
ALTER TABLE innodb_tb1 ENGINE=INNODB;
相应地，你也可以使用一个存储引擎指定的离线修复工具，例如myisamchk，或者导出数据再重新导入。然而，如果冲突发生在系统区，或者在数据表的数据行区域，而不是索引的话，你可能无法使用这些办法。这种情况下，你可能需要从你的备份中恢复数据或从冲突的文件中恢复数据。
如果你在InnoDB中也遇到了冲突，这会是极其严重的错误，你需要使用正确的方法去分析问题。InnoDB通常不会发生冲突。它的设计对冲突处理很健壮。冲突会是硬件故障（如内存区错误或磁盘错误），DBA的操作错误（如在MySQL环境外操作了数据库文件）或InnoDB自身的Bug (这种概率很低）的表现。通常的一个原因类似视图使用rsync工具创建备份的错误。这时没有可执行的查询——由于这会引起InnoDB的数据冲突，而你认为这会避免。如果你通过一个有问题的查询引起了InnoDB的数据冲突，那这并不是你的错误，这是InnoDB的Bug。
如果真的遇到了数据冲突，最重要的事情是搞清楚引起冲突的原因，在这之前不要简单地修复数据，也许这个冲突会自动消失。你可以通过innodb_force_recovery参数将InnoDB修改为强制恢复模式来修复数据（可以查阅MySQL的操作手册）。你也可以使用开源的Percona InnoDB数据恢复工具（www.percona.com/software/my…）从损坏的数据文件中提取数据。
更新索引统计
MySQL查询优化器在决定如何使用索引前，会调用两个API获取索引值的分布。第一个是records_in_range方法，该方法接收一个范围参数，然后返回该范围的结果数量。对于MyISAM引擎来说返回结果是准确的，但是对于InnoDB来说是估计值。
第二个API是info方法，该方法返回多种类型的数据，包括索引候选者（即每个索引对应的记录数量估计值）。
当存储引擎给查询优化器提供不太准确的数据行数信息，或查询计划过于复杂而无法估计准确的行数时，优化器使用索引统计去估计数据行数。MySQL优化器是基于查询代价做出决策的，最主要的代价准则就是这次查询会查找的数据量。如果索引统计从来没有生成，或者是过期了，优化器可能会做出错误的决定。解决的方案是运行ANALYZE TABLE命令，该命令会重建索引统计。
每个存储引擎实现索引统计的方式不同，因此你运行ANALUZE TABLE命令的频率也会不同，运行该命令的代价也不同，典型的存储引擎对索引统计处理方式如下：
Memory引擎不存储索引统计。
MyISAM在磁盘存储索引统计，并且ANALYZE TABLE在计算候选数据行的时候使用全索引扫描。整个表在这个过程中会被锁定。
InnoDB在MySQL 5.5版本中不在磁盘存储索引统计，而是通过随机的索引采样实现并且将结果存在内存中。
可以通过SHOW INDEX FROM命令检查索引的候选者。例如：
这个命令给了很多索引相关的信息，可以查阅MySQL的手册了解具体细节。这里需要特别关注的是Cardinality列。该列展示了存储引擎估计的索引对应了多少个不同的值。在MySQL 5.0及更新的版本中，也可以通过INFORMATION_SCHEMA.数据表中获取这些信息,这十分方便,例如,你可以根据INFORMATION_SCHEMA查询去找到那些低筛选性的索引。但是注意,对于数据量庞大的服务器,这些中间表可能会导致服务器的负荷大量增加。
