If you use the InnoDB storage engine for (some of) your MySQL tables, you’ve probably already came across a problem with its default configuration. As you may have noticed in your MySQL’s data directory (in Debian/Ubuntu – /var/lib/mysql) lies a file called ‘ibdata1′. It holds almost all the InnoDB data (it’s not a transaction log) of the MySQL instance and could get quite big. By default this file has a initial size of 10Mb and it automatically extends. Unfortunately, by design InnoDB data files cannot be shrinked. That’s why DELETEs, TRUNCATEs, DROPs, etc. will not reclaim the space used by the file.

我想你可以在那里找到很好的解释和解决方案:

http://vdachev.net/2007/02/22/mysql-reducing-ibdata1/

快速脚本接受的答案的过程在bash:

#!/usr/bin/env bash
dbs=$(mysql -BNe 'show databases' | grep -vE '^mysql$|^(performance|information)_schema$')
mysqldump --events --triggers --databases $dbs > alldatabases.sql && \
    echo "$dbs" | while read -r db; do
        mysqladmin drop "$db"
    done && \
    mysql -e 'SET GLOBAL innodb_fast_shutdown = 0' && \
    /etc/init.d/mysql stop && \
    rm -f /var/lib/mysql/ib{data1,_logfile*} && \
    /etc/init.d/mysql start && \
    mysql < alldatabases.sql

保存为purge_binlogs.sh并以root用户运行。

不包括mysql, information_schema, performance_schema(和binlog目录)。

假设您在/root/.my.cnf中有管理员凭证，并且您的数据库位于默认的/var/lib/mysql目录中。

您也可以在运行此脚本后清除二进制日志，以重新获得更多的磁盘空间:

PURGE BINARY LOGS BEFORE CURRENT_TIMESTAMP;

If you use the InnoDB storage engine for (some of) your MySQL tables, you’ve probably already came across a problem with its default configuration. As you may have noticed in your MySQL’s data directory (in Debian/Ubuntu – /var/lib/mysql) lies a file called ‘ibdata1′. It holds almost all the InnoDB data (it’s not a transaction log) of the MySQL instance and could get quite big. By default this file has a initial size of 10Mb and it automatically extends. Unfortunately, by design InnoDB data files cannot be shrinked. That’s why DELETEs, TRUNCATEs, DROPs, etc. will not reclaim the space used by the file.

我想你可以在那里找到很好的解释和解决方案:

http://vdachev.net/2007/02/22/mysql-reducing-ibdata1/

如果您的目标是监视MySQL的空闲空间，而您又不能停止MySQL来缩小ibdata文件，那么可以通过表状态命令来获取它。例子:

MySQL > 5.1.24:

mysqlshow --status myInnodbDatabase myTable | awk '{print $20}'

MySQL < 5.1.24:

mysqlshow --status myInnodbDatabase myTable | awk '{print $35}'

然后将这个值与ibdata文件进行比较:

du -b ibdata1

来源:http://dev.mysql.com/doc/refman/5.1/en/show-table-status.html

如前所述，您不能收缩ibdata1(为此需要转储和重新构建)，但通常也没有真正的必要。

使用autoextend(可能是最常见的大小设置)，ibdata1预分配存储空间，在存储空间接近满时增长。这使得写入速度更快，因为已经分配了空间。

当你删除数据时，它不会缩小，但文件内部的空间被标记为未使用。现在，当您插入新数据时，它将在进一步增长文件之前重用文件中的空白空间。

所以只有当你真的需要这些数据时，它才会继续增长。除非您确实需要为另一个应用程序使用空间，否则可能没有理由缩小它。

当你删除innodb表时，MySQL不会释放ibdata文件中的空间，这就是为什么它一直在增长。这些文件几乎从不缩小。

如何缩小现有的ibdata文件:

https://dev.mysql.com/doc/refman/5.6/en/innodb-system-tablespace.html#innodb-resize-system-tablespace

您可以编写脚本，并安排脚本在固定的时间后运行，但对于上面描述的设置，多个表空间似乎是更简单的解决方案。

如果使用配置选项innodb_file_per_table，则会创建多个表空间。也就是说，MySQL为每个表创建单独的文件，而不是一个共享文件。这些单独的文件存储在数据库的目录中，当您删除该数据库时，它们将被删除。在您的情况下，这样就不需要收缩/清除ibdata文件了。

关于多个表空间的更多信息:

https://dev.mysql.com/doc/refman/5.6/en/innodb-file-per-table-tablespaces.html