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

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

找到和修复损坏的表

最差的事情莫过于表已经损坏了。对于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来生成统计数据。

每个存储引擎生成索引的统计数据各不相同，索引你使用ANALYZE TABLE的频率也不同，同样的消耗成本也不同：

Memory存储引擎不会存储索引统计信息。

MyISAM在硬盘上存储统计信息，并且ANALYZE TABLE执行了全索引扫描来计算。这个过程这张表是锁定的。

InnoDB并不是在硬盘上存储统计信息。但是使用随机索引进入首次打开的表的方法来估算它们。对于InnoDB，ANALYZE TABLE使用的是随机的方式。因此统计结果不精确的，它们不需要手动更新，除非你运行了很长时间。ANALYZE TABLE也不回加锁消耗也相对低些。因此你可以在线的更新统计信息而不会影响正常工作。

你可以使用SHOW INDEX FROM来查看索引信息。

mysql> SHOW INDEX FROM sakila.actorG
*************************** 1. row ***************************
Table: actor
Non_unique: 0
Key_name: PRIMARY
Seq_in_index: 1
Column_name: actor_id
Collation: A
Cardinality: 200
Sub_part: NULL
Packed: NULL
Null:
Index_type: BTREE
Comment:
*************************** 2. row ***************************
Table: actor
Non_unique: 1
Key_name: idx_actor_last_name
Seq_in_index: 1
Column_name: last_name
Collation: A
Cardinality: 200
Sub_part: NULL
Packed: NULL
Null:
Index_type: BTREE

给出了很多索引信息。MySQL文档有详细说明。我们要注意的是Cardinality。这显示了在索引中存储引擎估算了多少个唯一的值。MySQL5.0中你也可以在INFORMATION_SCHEMA.STATISTICS表中获得这些信息，这样更方便了。举个例子，如果你可以写一条查询INFORMATION_SCHEMA的语句，来发现选择性更低的索引。