MySQL ERROR 1114 时先区分数据目录、tmpdir、临时表空间与目标表空间，再决定止损、SQL 优化或扩容。
先查“哪个文件系统或表空间满了”，不要看到表名就删数据：MySQL 报 ERROR 1114 (HY000): The table '...' is full 时，最常见的检查顺序是数据目录所在文件系统、MySQL 临时目录、InnoDB 临时表空间和目标表空间。先从 SSH 或宝塔终端保存完整 SQL、表名和时间，再查看 df -h、df -i、@@datadir、@@tmpdir 与表引擎。不要直接执行 TRUNCATE、删除 ibdata/ibtmp1 或重装数据库。
只读检查通常不收费。扩容云盘、增加数据库存储、恢复备份或迁移实例可能收费，提交前要到云平台账单与变更页核对。ERROR 1114 不等于目标表已经损坏，但写入、导入、索引重建和大查询可能处于失败或等待状态；误删表空间文件会造成数据丢失。生产处理前应确认最近可用备份或快照、数据库版本、存储引擎和可用维护窗口。
ERROR 1114 为什么不一定是“这张表行数太多”
MySQL 官方错误说明把 ERROR 1114 定义为 ER_RECORD_FILE_FULL，文字只是“表已满”。真正边界可能来自磁盘、inode、文件大小、表空间最大值或临时空间。报错里的名称也很关键：普通业务表名更偏向数据表空间；#sql... 等临时名称常出现在排序、分组、索引或表重建的中间阶段。
| 报错与现场 | 优先怀疑 | 安全处理方向 |
|---|---|---|
| 数据目录分区或 inode 100% | MySQL 无法扩展数据、日志或临时文件 | 先停止异常增长，确认文件用途后释放空间或扩容 |
/tmp/#sql... 且 tmpdir 分区满 | 排序、分组、导入或 DDL 的临时文件耗尽空间 | 终止高成本语句或为 tmpdir 提供受控空间 |
| 实际表名且磁盘仍有空间 | 表空间 max、文件系统单文件限制或存储引擎限制 | 读取表引擎和表空间配置，按官方流程扩展 |
| 只有某条 GROUP BY/ORDER BY 失败 | 内部临时表或 TempTable 资源边界 | 用 EXPLAIN 与临时表指标确认，不先放大全局内存 |
| 托管数据库显示存储耗尽 | 实例存储、自动扩展上限或临时空间限制 | 从云控制台核对实际可用存储和扩展条件 |
第一步：只读确认磁盘、inode 与 MySQL 路径
以下命令不会修改数据库。路径、表名和配置可能暴露业务信息，对外分享前应脱敏。登录 MySQL 时使用交互式 -p 或受控登录配置，不在命令行写明密码。
df -Th
df -ih
sudo lsblk -f
mysql -u YOUR_ADMIN_USER -p -e "SELECT @@version, @@datadir, @@tmpdir, @@innodb_temp_data_file_path;"把 YOUR_ADMIN_USER 换成具备只读查看变量权限的实际账号。分别对 @@datadir 和 @@tmpdir 所在挂载点执行 df，不能只看根分区。容量未满但 inode 为 100% 时，同样无法新建文件；空间看似充足时还要确认云盘是否已经扩容但分区或文件系统尚未扩展。
如果 df 很满而目录统计找不到对应文件，可能存在已删除但仍被 mysqld 打开的临时文件。先按Linux 磁盘满排查使用 lsof +L1 确认进程，不要直接操作 /proc 中的文件描述符。
第二步：确认失败对象是业务表还是临时表
先保存应用日志或 MySQL 错误中的完整表名与 SQL 类型，再用只读查询确认目标表的引擎、大小和表空间。下面的库名和表名必须替换；如果报错对象是 #sql...，不要照搬成永久表查询。
SELECT TABLE_SCHEMA, TABLE_NAME, ENGINE,
TABLE_ROWS, DATA_LENGTH, INDEX_LENGTH, DATA_FREE
FROM information_schema.TABLES
WHERE TABLE_SCHEMA = 'YOUR_DATABASE'
AND TABLE_NAME = 'YOUR_TABLE';
SHOW CREATE TABLE `YOUR_DATABASE`.`YOUR_TABLE`;TABLE_ROWS 对 InnoDB 常是估算值，不能据此认定达到行数上限。SHOW CREATE TABLE 用来确认引擎、分区和表空间声明，不应把完整表结构公开。若报错发生在导入、ALTER TABLE、OPTIMIZE TABLE、创建索引或复杂查询中，中间文件所需空间可能显著高于最终数据增量。
第三步：检查 MySQL 临时目录与临时表空间
MySQL 会在排序、分组、表重建和部分 DDL 中创建临时文件或内部临时表。官方文档说明，Unix 上的普通临时文件位置由 TMPDIR 或 tmpdir 决定；InnoDB 的内部磁盘临时表和用户临时表则可能使用会话临时表空间，默认位于数据目录下的 #innodb_temp。全局临时表空间 ibtmp1 还有独立的 innodb_temp_data_file_path 配置。
SHOW VARIABLES WHERE Variable_name IN (
'tmpdir',
'tmp_table_size',
'max_heap_table_size',
'temptable_max_ram',
'innodb_temp_data_file_path',
'innodb_temp_tablespaces_dir'
);
SHOW GLOBAL STATUS WHERE Variable_name IN (
'Created_tmp_tables',
'Created_tmp_disk_tables'
);变量是否存在取决于 MySQL 版本；MariaDB 也可能使用不同实现，不能把 MySQL 8.4 的参数直接写入其他版本。Created_tmp_disk_tables 是累计指标，需要与故障时间前后的增量和具体 SQL 对照。看到磁盘临时表多，不代表应该直接提高 tmp_table_size：全局放大每个连接可用内存，可能引发系统 OOM。
如果 ibtmp1 很大，正常关闭并重启 MySQL 会重建全局临时表空间，但重启会中断连接，且不能修复正在快速制造临时数据的 SQL。只有完成备份、确认服务能正常关闭并安排维护窗口后，才考虑此动作。运行中绝对不要手工删除 ibtmp1，也不要把删除 ibdata1 当作同一种操作。
第四步：磁盘满时先止损，再决定清理还是扩容
先找出正在增长的是数据库数据、二进制日志、普通日志、备份文件还是临时文件。以下只读命令需要按真实路径缩小范围，避免在大型文件系统无边界扫描：
sudo du -xhd1 /var/lib/mysql
sudo du -xhd1 /var/log
sudo lsof +L1 | grep -E 'mysqld|mysql'
sudo journalctl --disk-usage确认是过期备份或已经归档的日志后，按现有保留策略清理；二进制日志应通过 MySQL 的保留与清理机制处理，不能在文件系统中直接删除未知 binlog。业务数据正常增长时优先扩容云盘或托管数据库存储，再按分区和文件系统步骤完成扩展。扩容只增加块设备但未扩文件系统，MySQL 看到的可用空间不会变化。
如果空间耗尽由单条导入、索引重建或报表 SQL 触发，可在确认业务影响后停止该任务，先恢复关键写入，再把任务移到有足够临时空间的维护窗口。不要一边空间告急一边重复提交同一导入或 DDL。
第五步：磁盘没满时核对表空间上限
使用 InnoDB 时，确认目标表位于 file-per-table、通用表空间还是系统表空间。配置中如果为数据文件或临时表空间设置了 max，文件即使所在磁盘有空闲，也可能到达配置上限。读取当前表空间元数据：
SELECT FILE_NAME, TABLESPACE_NAME, ENGINE,
INITIAL_SIZE, TOTAL_EXTENTS * EXTENT_SIZE AS total_size_bytes,
DATA_FREE, MAXIMUM_SIZE
FROM information_schema.FILES
WHERE ENGINE = 'InnoDB';结果字段在不同版本和表空间类型下可能为空或需要额外权限。若确认系统表空间或全局临时表空间达到显式最大值，应按当前 MySQL 版本的官方配置语法规划扩展，并在测试环境验证启动。不要在线移动 .ibd、ibdata 或 undo 文件，也不要只改配置而不检查目标磁盘余量和备份。
复杂查询为什么会让临时空间耗尽
大范围 GROUP BY、ORDER BY、DISTINCT、窗口函数、派生表和索引重建可能产生磁盘临时表或临时文件。先对原始 SQL 使用 EXPLAIN，确认扫描行数、排序和临时表，再考虑增加合适索引、减少无用列、缩小时间范围或分批处理。不要直接在高峰生产库运行 EXPLAIN ANALYZE；它会真实执行语句。
如果故障根因是慢查询和高成本排序，可结合MySQL 慢查询排查建立执行计划与上线验证。修复 SQL 后还要观察临时表指标、磁盘增长和查询结果正确性，不能只以“ERROR 1114 暂时消失”为结束。
宝塔和托管数据库分别从哪里看
宝塔用户可先进入“首页”查看磁盘概况，再到“软件商店 → 已安装 → MySQL”查看配置与日志，同时用 SSH 核对真实挂载点。面板百分比只能帮助定位，不能替代 df、MySQL 变量与表空间信息。不要在面板中直接点重装数据库，也不要把数据目录递归改成 777。
托管 MySQL 通常不能登录宿主机，也不能手工删除临时文件。应在云控制台查看实例存储使用率、自动扩展上限、只读或磁盘满事件和失败 SQL，再按产品支持的扩容或参数流程处理。不同云平台、实例规格和计费方式会变化，费用和是否需要重启以当前控制台为准。
修复后怎样验收
- 原失败写入、导入或查询在受控小范围内成功，返回行数和业务结果正确。
- 数据目录、tmpdir、inode 与表空间都保留安全余量，没有继续快速增长。
- MySQL 错误日志没有新的 ERROR 1114、I/O error、只读或表恢复异常。
- 网站前台、后台写入、队列和定时任务恢复，不只验证一条 SQL。
- 扩容或 SQL 优化后继续观察至少一个业务高峰，确认问题没有转化为 OOM 或慢查询。
如果网站同时报数据库无法连接，应先用WordPress 数据库连接排查区分服务、认证和存储故障；ERROR 1114 处理的是数据库已经执行到需要更多存储或临时空间的阶段，与登录失败不是同一意图。
回退与恢复边界
参数或路径调整导致 MySQL 无法启动时，恢复上一版配置并从控制台确认磁盘仍有余量；不要连续修改多个表空间参数。扩容后业务异常时，不应尝试缩小已经扩展的文件系统，先保持新容量并回退应用或 SQL 变更。出现表损坏、I/O 错误或误删文件迹象时立即停止写入，从快照或数据库备份副本验证恢复，不覆盖唯一生产数据。
联系 Telegram 客服 