1114 (HY000): 表已满答案

【问题标题】：1114 (HY000): The table is full1114 (HY000): 表已满
【发布时间】：2010-10-18 08:26:01
【问题描述】：

我正在尝试通过简单的查询向InnoDB 表添加一行：

INSERT INTO zip_codes (zip_code, city) VALUES ('90210', 'Beverly Hills');

但是当我尝试这个查询时，我得到以下信息：

ERROR 1114 (HY000)：表 zip_codes 已满

做一个

SELECT COUNT(*) FROM zip_codes

给了我 188,959 行，考虑到我在同一个数据库中有另一个包含 810,635 行的表，这似乎不算太多。

我对@987654325@ 相当缺乏经验，也从未遇到过MyISAM 的这个问题。这里有哪些潜在问题？

编辑：这只发生在向zip_codes 表中添加一行时。

【问题讨论】：

当您尝试插入任何表时是否会出现错误，还是仅插入 zip_codes 一个？

标签： mysql innodb

【解决方案1】：

编辑：首先检查，如果您没有用完磁盘空间，然后再解决与配置相关的解决方案。

在您的my.cnf 中，您的innodb_data_file_path 的最大尺寸似乎太小了，在这个例子中

innodb_data_file_path = ibdata1:10M:autoextend:max:512M

你不能在所有 innodb 表中托管超过 512MB 的数据。

也许您应该使用innodb_file_per_table 切换到innodb-per-table 方案。

【讨论】：

C 我们在 ubuntu 中得到这个 my.cnf 文件
@Nadh 在 Ubuntu 16.04 中，它是 /etc/mysql/ 的一部分，并在 /etc/mysql/conf.d 中部分拆分为其他文件
将innodb_data_file_path 行添加到/etc/mysql/mysql.conf.d/mysqld.cnf 并重新启动mysql 和apache2 服务后，我的工作正常

【解决方案2】：

另一个可能的原因是分区已满 - 这就是我现在发生的情况。

【讨论】：

这应该始终是要检查的第一件事。总是回到电源线，我偶然发现了很多次。
您在尝试更改 mysql 配置时为我节省了几个小时。主分区已满。不得不将mysql数据库移动到数据分区，然后创建一个软链接
使用df -h检查磁盘大小
这应该始终是要检查的第一件事。但通常当mysql给出错误时它会删除数据。并且分区未满。

【解决方案3】：

你也会得到同样的错误 ERROR 1114 (HY000): The table '#sql-310a_8867d7f' is full

如果您尝试向使用存储引擎 MEMORY 的表添加索引。

【讨论】：

这发生在我身上，但我的客户似乎使用了错误的语法。当使用简单的ALTER TABLE my_table ADD INDEX my_index (column_a, column_b); 添加相同的索引时，它起作用了。

【解决方案4】：

您需要修改在 my.cnf 中为 INNO_DB 表设置的限制上限。此内存限制不是为单个表设置的，而是为所有组合的表设置的。

如果您希望内存自动扩展至 512MB

innodb_data_file_path = ibdata1:10M:autoextend:max:512M

如果不知道限制或者不想设置限制上限，可以这样修改

innodb_data_file_path = ibdata1:10M:autoextend

【讨论】：

我们在亚马逊上托管了我们的 ddbb，并配置了自动扩展。但是我们遇到了同样的问题，我认为是由于达到了配置的存储限制

【解决方案5】：

DOCKER 用户：当您达到 Docker 映像大小 限制的 90% 左右时也会发生这种情况（似乎缓存需要 10% 左右）。措辞令人困惑，因为这仅仅意味着 Docker 可以用于基本上所有事情的磁盘空间量。

要修复，请转到 Docker 桌面设置 > 磁盘 > 将滑块向右移动一点 > 应用。

【讨论】：

【解决方案6】：

如果tmpdir 所在的分区已满（由于更改表或其他原因），也会出现此错误

【讨论】：

【解决方案7】：

在我的情况下，这是因为托管 ibdata1 文件的分区已满。

【讨论】：

【解决方案8】：

存储 mysql 表的分区（通常是 /var/lib/mysql）或存储临时表的分区（通常是 /tmp）可能空间不足。

您可能希望： - 在索引创建期间监控您的可用空间。 - 将 tmpdir MySQL 变量指向不同的位置。这需要重新启动服务器。

【讨论】：

【解决方案9】：

我在导入 8GB 的 sql 数据库文件时也遇到了这个错误。检查了我的mysql安装驱动器。 驱动器中没有剩余空间。因此通过删除不需要的项目获得一些空间并重新运行我的数据库导入命令。 这次成功了。

【讨论】：

【解决方案10】：

除非您启用了innodb_file_per_table 选项，否则InnoDB 会将所有数据保存在一个文件中，通常称为ibdata1。

检查该文件的大小并检查它所在的驱动器中有足够的磁盘空间。

【讨论】：

【解决方案11】：

如果你使用NDBCLUSTER作为存储引擎，你应该增加DataMemory和IndexMemory。

Mysql FQA

【讨论】：

【解决方案12】：

我们有：SQLSTATE[HY000]：一般错误：1114 表 'catalog_product_index_price_bundle_sel_tmp' 已满

解决：

编辑数据库配置：

纳米/etc/my.cnf

tmp_table_size=256M max_heap_table_size=256M

重启数据库

【讨论】：

那些 512M 设置很危险。它们控制复杂选择中临时表的最大内存大小。它不仅是“每个连接”，而且是“每个 tmp 表”。因此，这些值很容易导致您耗尽 RAM。

【解决方案13】：

在我的情况下，只是因为 mysql 服务器与应用程序一起运行，而应用程序写入了太多日志，导致磁盘已满。

你可以检查磁盘是否有足够的空间使用

df -h

如果磁盘使用百分比为100%，可以使用该命令查找哪个目录过大

du -h -d 1 /

【讨论】：

【解决方案14】：

引用 MySQL 文档。

InnoDB 存储引擎在可以从多个文件创建的表空间中维护 InnoDB 表。这允许表超过单个文件的最大大小。表空间可以包括原始磁盘分区，这允许非常大的表。最大表空间大小为 64TB。

如果您正在使用 InnoDB 表并且 InnoDB 表空间中的空间不足。在这种情况下，解决方案是扩展 InnoDB 表空间。请参阅第 13.2.5 节，[“添加、删除或调整 InnoDB 数据和日志文件”。]

【讨论】：

【解决方案15】：

在 CentOS 7 上，只需停止和启动 MySQL 服务即可为我解决此问题。

sudo service mysql stop

sudo service mysql start

【讨论】：

奇怪的是，这对我也有用....没有任何分区超过 80% 并且只是重新启动修复它。

【解决方案16】：

由于磁盘空间不足，我遇到了同样的问题。并且托管 ibdata1 文件的分区是 InnoDB 基础设施的系统表空间已满。

【讨论】：

【解决方案17】：

我遇到了这个问题...在我的情况下，我的专用服务器上的存储空间不足。检查其他一切是否都失败并考虑增加磁盘空间或删除不需要的数据或文件。

【讨论】：

【解决方案18】：

就我而言，我试图运行一个 alter table 命令，但可用磁盘空间小于表的大小。有一次，我增加了磁盘空间，问题就消失了。

【讨论】：

我在更改表格时遇到了同样的问题。但我在 vm 中没有太多空间。我该怎么办？我可以从其他虚拟机执行此操作吗？

【解决方案19】：

这个磁盘在 /var/www/mysql 已满

【讨论】：

【解决方案20】：

对于那些在尝试增加任何各种内存限制时问题仍然存在的人：通过设置 internal_tmp_mem_storage_engine=MEMORY 为我解决了问题。

我在 Ubuntu 20.04.2 上，使用 MySQL 8.0.25-0ubuntu0.20.04.1。

【讨论】：

此解决方案也适用于 Windows 10、MySQL 8.0.26。谢谢。
这与此bug 有关。根据错误报告，它将在 MySQL 8.0.27 中解决。

【解决方案21】：

在我的情况下，服务器内存已满，因此数据库无法写入临时数据。要解决它，您只需在驱动器上留出一些位置。

【讨论】：

【解决方案22】：

我通过增加数据库所在的 vagrant VM 的可用内存量来解决此问题。

【讨论】：

【解决方案23】：

这也可能是 InnoDB 对打开事务数的限制：

http://bugs.mysql.com/bug.php?id=26590

在 1024 个事务中，具有撤消功能记录（如编辑任何数据）， InnoDB 将无法工作

【讨论】：

答案已经过时了。