The table '#sql-fb5_190a57' is full Operation failed

1.版本

1)操作系统

cat /etc/issue

cat /etc/issue

CentOS release 6.6 (Final)

Kernel \r on an \m

cat /proc/version

cat /proc/version

Linux version 2.6.32-504.el6.x86_64 (mockbuild@c6b9.bsys.dev.centos.org) (gcc version 4.4.7 20120313 (Red Hat 4.4.7-11) (GCC) ) #1 SMP Wed Oct 15 04:27:16 UTC 2014

2)mysql数据库版本

5.1 及5.6

2. 问题描述

今天一个朋友跟我问了一个问题，他说他在对一个大表(innodb)进行optimize操作的时候报如下错误：

The table '#sql-fb5_190a57' is full   Operation failed

3. 问题原因

一看到这个报错，当时第一反应就是他的tmpdir指定的temp空间太小。让他指定一个新的足够大的temp空间，但是结果问题依旧。(后来发现自己太武断了，都没有问他数据库版本，就直接判断问题)。

这个报错的原因很简单，在optimize操作过程中会产生临时文件，如上报错中显示的文件 '#sql-fb5_190a57' ，该文件所在空间空间不足时就会报如上错误。但是他df -h发现/tmp目录没有被使用，反而是数据库datadir目录使用率100%。(NOTE:他的mysql版本是5.1)

在mysql 5.1官方文档“Where MySQL Stores Temporary Files”部分可以发现如下内容：

For some SELECT queries, MySQL also creates temporary SQL tables. These are not hidden and have names of the form SQL_*.

ALTER TABLE creates a temporary copy of the original table in the same directory as the original table.

##在mysql 5.1中由select语句产生的临时文件存储在由tmpdir参数指定的临时表空间中(这些文件是不可见的，可以通过lsof +L1|grep mysqld观察这些文件)。由alter table等产生的临时文件存储在该表所在目录下.(这就是为什么他的/tmp目录没有使用，但是datadir目录使用率100%的原因)。

NOTE:mysql 5.1和mysql 5.6中临时文件存储还是有很大不同的，具体的可以参见我的另一篇博客：

4. 解决方案

4.1 方案1

添加datadir目录磁盘空间，再执行optimize table table_name;命令
NOTE:在5.6.17之前 optimize 操作是会锁表的(阻塞所有dml操作)

4. 方案2

停掉该表相关应用，对表进行导出，然后重新导入(不要在业务高峰期操作)