1114(HY000) : 桌子满了

我试图用一个简单的查询向 InnoDB表添加一行:

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

但是当我尝试这个查询时，我得到了以下结果:

错误1114(HY000) : 表 zip_codes已满

做一个

SELECT COUNT(*) FROM zip_codes

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

我是相当缺乏经验的 InnoDB engine和从来没有经历过这个问题与 MyISAM。这里有哪些潜在的问题？

编辑: 只有在向 zip_codes表添加一行时才会发生这种情况。

291162 次浏览
小开

引用 MySQL 文档。

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

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

小开
最佳答案

编辑: 在解析到与配置相关的分辨率之前，首先检查是否没有用完磁盘空间。

你似乎有一个太低的最大大小为您的 innodb_data_file_path在您的 my.cnf，在这个例子

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

您不能将超过512MB 的数据存储在所有的 inodb 表中。

也许您应该使用 innodb_file_per_table切换到每个表都可以创新的方案。

小开

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

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

小开

这也可能是 InnoDB 对开放事务数量的限制:

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

在1024个事务中，有撤消 记录(例如，编辑任何数据) , InnoDB 将无法工作

小开

您需要修改 my.cnf 中为 INNO _ DB 表设置的限制上限。这个内存限制不是针对单个表设置的，而是针对所有合并的表设置的。

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

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

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

innodb_data_file_path = ibdata1:10M:autoextend
小开

在我的例子中，这是因为承载 ibdata1文件的分区已满。

小开

您还将得到相同的错误 ERROR 1114(HY000) : 表“ # sql-310a _ 8867d7f”已满

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

小开

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

小开

如果驻留 tmpdir的分区填满(由于 alter 表或其他表的原因) ，也会出现此错误

小开

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

Mysql FQA

小开

您可能会在存储 mysql 表的分区(通常是/var/lib/mysql)或存储临时表的分区(通常是/tmp)中耗尽空间。

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

小开

我们有: SQLSTATE [ HY000] : 常见错误: 1114表‘ catalog _ product _ index _ price _ bundle _ sel _ tmp’已满

解决方法:

Db 的编辑配置:

Nano/etc/my.cnf

Tmp _ table _ size = 256M Max _ heap _ table _ size = 256M

  • 重新启动数据库
小开

在我的例子中，服务器内存已满，因此 DB 无法写入临时数据。 要解决这个问题，你只需要在硬盘上找个地方。

小开

在 CentOS 7上，只需停止和启动 MySQL 服务就可以修复这个问题。

sudo service mysql stop

sudo service mysql start

小开

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

小开

由于磁盘空间较小，我面临同样的问题。而托管 ibdata1文件的分区(即 InnoDB 基础设施的系统表空间)已满。

小开

我正在经历这个问题... 对我来说，我的专有服务器已经用完了。检查是否所有其他操作都失败，并考虑增加磁盘空间或删除不需要的数据或文件。

小开

我通过增加数据库所在的流浪 VM 的可用内存量来解决这个问题。

小开

在我的例子中，我试图运行一个 alter table 命令，可用的磁盘空间小于表的大小。有一次，我增加了磁盘空间，问题就解决了。

小开

在我的例子中，仅仅是因为 mysql 服务器与应用程序一起运行，应用程序写了太多的日志，导致磁盘已满。

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

df -h

如果磁盘使用率为100% ，则可以使用此命令查找哪个目录太大

du -h -d 1 /
小开

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

要修复，进入 Docker 桌面设置 > 磁盘 > 向右移动滑块 > 应用。

enter image description here

小开

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

小开

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

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


提交答案