对mysql表进行优化、分析、检查和修复的说明

对数据库的管理常规就是进行预防性的维护,以及修复那些出现问题的内容。

进行检查和修复通常具有四个主要的任务:

1. 对表进行优化

2. 对表进行分析(分析并存储MyISAM和BDB表中键的分布)

3. 对表进行检查(检查表的错误,并且为MyISAM更新键的统计内容)

4. 对表进行修复(修复被破坏的MyISAM表)

一、对表进行优化

优化表有很多方式实现: OPTIMIZE TABLE语句、mysqlcheck工具(服务器要运行)或myisamchk(服务器没有运行或表中没有交互)

为什么优化?随着MySQL的使用,包括BLOB和VARCHAR字节的表将变得比较繁冗,因为这些字段长度不同,对记录进行插入、更新或删除时,会占有不同大小的空间,记录就会变成碎片,且留下空闲的空间。像具有碎片的磁盘,会降低性能,需要整理,因此要优化。

1. 利用OPTIMIZE语句对表进行优化

# mysql>OPTIMIZE TABLE 表名

这样就对表名进行了优化。

2. 利用mysqlcheck对表进行优化

mysqlcheck可进行优化外,还可执行大量的检查和修复任务。

# mysqlcheck -o 数据库名 表名 -uroot -p111111 (一张表)

# mysqlcheck -o 数据库名 表名1 表名2 -uroot -p111111 (多张表)

# mysqlcheck -o 数据库名 -uroot -p111111 (对整个数据库)

3. 利用myisamchk对表进行优化

# myisamchk --quick --check-only-changed --sort-index --analyze 表名

# myisamchk -r 表名 (参数-r表示对表进行修复,同时也删去了浪费的空间)

# myisamchk -r /usr/local/mysql/data/testblog/article (指定表所在的路径)

以上操作需在服务器关闭或没有与服务器互操作的时候,可以使用myisamchk命令行工具(如果服务器正在运行,那么在运行这条语句之前利用mysqladmin flush-tables对表进行刷新。需确保服务器没有与表进行互操作,否则会出现故障)。myisamchk是最老的方法。必须在正确位置上运行myisamchk,或者指定表所在的路径。

注意:在优化过程中,表会被锁住,因此不要在忙时进行优化操作。同样,需要有足够的空间才能进行OPTIMIZE TABLE。如果没有磁盘空间,MySQL将不能进行优化,表也无法使用。

对MyISAM表,optimize table如下工作:

1.若表有已删除行或拆分行,修复该表;

2.若索引页未排序,将其排序;

3.若表统计信息不是最新的(并且不能通过对索引进行排序来完成修复),更新之。

优化是对包含MyISAM表的数据库的常规管理事务中一个重要环节,应该定期进行。

二、对表进行分析

对表的定期分析可以改善性能,且应该成为常规维护工作的一部分。因为通过更新表的索引信息对表进行分析,可改善数据库性能。

Analyze 用来分析和存储表的关键字的分布,使得系统获得准确的统计信息,影响 SQL 的执行计划的生成。对于数据基本没有发生变化的表,是不需要经常进行表分析的。但是如果表的数据量变化很明显,用户感觉实际的执行计划和预期的执行计划不 同的时候,执行一次表分析可能有助于产生预期的执行计划。

有三种方法可以对表进行分析:

1. 连接到MySQL时,使用ANALYZE TABLE语句

2. 利用mysqlcheck命令行工具(服务器需要运行,并且只对MyISAM表起作用)

3. 利用myisamchk命令行工具(服务器不应该运行,或无对所操作的表发生互操作)

# ANALYZE TABLE 表名;

# mysqlcheck -a 数据库名 表名 -uroot -p111111

# mysqlcheck -a 数据库名 表名1 表名2 -uroot -p111111

如果试图对不支持分析操作的表进行分析(如InnoDB),那操作将无法进行

# myisamchk -a /usr/local/mysql/data/数据库/表名

ANALYZE TABLE的作用:

  • 统计索引分布信息。

  • 对于 MyISAM 表,相当于执行了一次 myisamchk --analyze

  • 支持 InnoDB.NDB.MyISAM 等存储引擎,但不支持视图(view)

  • 执行时,会对表加上读锁(read lock)

  • 该操作会记录binlog,可以在analyze和table之间添加关键字local取消写入

ANALYZE TABLE风险:

  • analyze table的需要扫描的page代价粗略估算公式:sample_pages * 索引数 * 表分区数。

  • 因此,索引数量较多,或者表分区数量较多时,可能会比较费时,要评估代价,并默认只在负载低谷时执行。

  • 如果某个表上当前有慢SQL,此时执行analyze table,则该表后续的查询均会处于waiting for table flush的状态,严重的话会影响业务,因此执行前必须先检查有无慢查询。