快速脚本接受的答案的过程在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;

如果您的目标是监视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

快速脚本接受的答案的过程在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;

在新版的mysql服务器菜谱上面会粉碎“mysql”数据库。 在旧版本中，它是有效的。在new中，一些表切换到INNODB类型，这样做会损坏它们。 最简单的方法是:

转储所有数据库 卸载mysql服务器, 添加remain my.cnf:

    [mysqld]
    innodb_file_per_table=1

删除/var/lib/mysql中的所有文件 安装mysql服务器 恢复用户和数据库

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/

似乎没有人提到innodb_undo_log_truncate设置可能产生的影响。

在阅读了Percona关于这个主题的博客文章后，我在MariaDB 10.6中启用了截断UNDO LOG条目的功能，它填充了ibdata1的95%，在完全删除和恢复之后，从那时起，ibdata1就不再增长了。

在默认innodb_undo_log_truncate = 0的情况下，我的ibdata1很容易就达到了数据库空间占用的10%，也就是几十gb。

innodb_undo_log_truncate = 1时，ibdata1的大小为76 Mb。