• /var/lib/mysql/mydb/mytable.frm
• /var/lib/mysql/mydb/mytable.ibd

.ibd将包含该表的数据页和索引页。

坏消息 : 你所做的就是从 ibdata中提取出 mydb.mytable的数据页和索引页。每个表的数据段落，包括 mydb.mytable，仍然保留在数据字典中(见 Ibdata1的图形化表示)。请注意，ibdata1根本没有缩水。

基础设施清理

要一劳永逸地缩小 ibdata1，你必须做到以下几点:

1. 将所有数据库转储(例如，使用 mysqldump)到一个 .sql文本文件中(下面使用 SQLData.sql)

2. 删除所有数据库(除了 mysql和 information_schema) 警告: 作为预防措施，请运行这个脚本，以确保所有用户授权都到位:

   mkdir /var/lib/mysql_grants
   cp /var/lib/mysql/mysql/* /var/lib/mysql_grants/.
   chown -R mysql:mysql /var/lib/mysql_grants
   

3. Login to mysql and run SET GLOBAL innodb_fast_shutdown = 0; (This will completely flush all remaining transactional changes from ib_logfile0 and ib_logfile1)

4. Shutdown MySQL

5. Add the following lines to /etc/my.cnf (or my.ini on Windows)

   [mysqld]
   innodb_file_per_table
   innodb_flush_method=O_DIRECT
   innodb_log_file_size=1G
   innodb_buffer_pool_size=4G
   

   (旁注: 不管你的 innodb_buffer_pool_size设置是什么，确保 innodb_log_file_size是 innodb_buffer_pool_size的25% 。

   另外: innodb_flush_method=O_DIRECT在 Windows 上不可用)

6. 删除 ibdata*和 ib_logfile*，也可以删除除 /var/lib/mysql/mysql以外的 /var/lib/mysql中的所有文件夹。

7. 启动 MySQL (这将在1G 时重新创建 ibdata1[默认为10MB ]和 ib_logfile0和 ib_logfile1)。

8. 进口 SQLData.sql

现在，ibdata1仍将增长，但只包含表元数据，因为每个 InnoDB 表都将存在于 ibdata1之外。ibdata1将不再包含 InnoDB 数据和其他表的索引。

例如，假设您有一个名为 mydb.mytable的 InnoDB 表。如果查看 /var/lib/mysql/mydb，您将看到表示该表的两个文件:

• mytable.frm(存储引擎头)
• 表格数据和索引

使用 /etc/my.cnf中的 innodb_file_per_table选项，您可以运行 OPTIMIZE TABLE mydb.mytable，而文件 /var/lib/mysql/mydb/mytable.ibd实际上将收缩。

在我作为 MySQL 数据库管理员的职业生涯中，我已经这样做过很多次了。事实上，我第一次这样做时，我将 50GB ibdata1文件缩小到只有500MB！

试试看。如果你还有什么问题，尽管问。相信我，这在短期和长期都是有效的。

警告

在步骤6中，如果由于 mysql模式开始被删除，mysql 无法重新启动，请回头看步骤2。您创建了 mysql模式的物理副本。你可以恢复如下:

mkdir /var/lib/mysql/mysql
cp /var/lib/mysql_grants/* /var/lib/mysql/mysql
chown -R mysql:mysql /var/lib/mysql/mysql

回到第6步，继续

更新2013-06-04美国东部时间11:13

关于在步骤5中将 Nodb _ log _ file _ size设置为 Inodb _ buffer _ pool _ size的25% ，这是一个相当古老的规则。

回到 July 03, 2006，Percona 写了一篇不错的文章 为什么要选择适当的 inodb _ log _ file _ size。之后，在 Nov 21, 2008，Percona 又写了一篇关于 如何计算适当的大小基于高峰工作负载保持一个小时的变化价值的文章。

此后，我在 DBA StackExchange 上撰写了关于计算日志大小的文章，并在其中引用了那两篇 Percona 文章。

• Aug 27, 2012: 在具有48GB RAM 的服务器上正确调优30GB InnoDB 表
• Jan 17, 2013: MySQL 5.5-Innodb-injdb _ log _ file _ size 大于4GB 的组合？

就个人而言，我仍然会采用初始设置的25% 规则。然后，随着生产时间的推移，可以更准确地确定工作负载，您可以调整日志的大小在一个维护周期内只需几分钟。