mysql optimize table

mysql 数据文件的使用是只扩展，不回收。对表执行delete之后,磁盘上数据文件是不会缩小的。

通常的做法，是先逻辑导出，然后truncate 原表（或者删除重建),再导入。

另外还有一种方法是optimize table ，但是有一定的限制。

 

同事问我在innodb 上一张200G+ 的表，使用了optimize table 整理碎片，回收空间时，执行了快3个小时，空间不仅没有减少，还增加了200多个G，磁盘空间都用光了。问我怎么处理。

这个问题之前也没有遇到过。所以今天学习并整理了下。

 关于optimize table 回收空间的效果这里不做演示，网上一大把。

 

1. 适用范围

 

OPTIMIZE TABLE只对MyISAM, BDB和InnoDB表起作用。

 三种不同的存储引擎，optimize table 的处理逻辑是不一样的。最关键的就是这个处理逻辑：

 

MyISAM：

1.如果表已经删除或分解了行,则修复表。

2.如果未对索引页进行分类,则进行分类。

3.如果表的统计数据没有更新（并且通过对索引进行分类不能实现修复）,则进行更新。

 

BDB：

OPTIMIZE TABLE目前被映射到ANALYZE TABLE上。

 

INNODB:

OPTIMIZE TABLE被映射到ALTER TABLE ... FORCE ,这会重建表。重建操作能更新索引统计数据并释放成簇索引中的未使用的空间。

在5.6.17之前，optimize table 会锁表，从5.6.17开始，optimize table 变成在线操作，表锁只会发生在解析和提交两个阶段, 这两个过程是极短的，可以忽略。

也就是说，对DML操作基本不会引起堵塞。

 

当满足以下两个条件时，mysql 会使用copy 方法复制数据（copy的速度比insert要快）：

• 开启mysqld --skip-new 选项
• old_alter_table 系统变量设置为enable状态

需要注意的是，如果表上包含fulltext索引，optimize table 操作使用的是copy method ，而不会选择online在线的方式

 

 

2. 不在binlog中记录optimize table 操作

 

OPTIMIZE NO_WRITE_TO_BINLOG TABLE 

 

3. 遇到的问题

如果在使用optimize的时候遇到如下错误：

root@rac1 : test 22:10:22> optimize table tab;

+----------+----------+----------+-------------------------------------------------------------------+

| Table    | Op       | Msg_type | Msg_text                                                          |

+----------+----------+----------+-------------------------------------------------------------------+

| test.tab | optimize | note     | Table does not support optimize, doing recreate + analyze instead |

| test.tab | optimize | status   | OK                                                                |

+----------+----------+----------+-------------------------------------------------------------------+

2 rows in set (29.88 sec)

使用--skip-new或--safe-mode选项可以启动mysqld。通过启动mysqld,您可以使OPTIMIZE TABLE对其它表类型起作用。