维护表有三个主要的目的:
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
也可以先删除索引,重建表,最后重新创建索引来实现。
索引的介绍就先到这里了,明天进入查询性能优化部分!