执行INSERT、ALTER TABLE或复杂查询时，MySQL可能返回 ERROR 1114 (HY000): The table '...' is full。错误文字看起来像表达到行数上限，但实际含义取决于对象使用的存储引擎、表空间和临时文件位置；根分区仍有空间时也可能发生。
不要一看到1114就直接调大内存参数或删除数据库文件。 先确认报错对象是业务表还是内部临时表，再判断限制来自磁盘、inode、表空间、容器配额还是引擎上限。
先确认报错对象和存储引擎
记录完整SQL、表名和MySQL错误日志时间点：
sudo journalctl -u mysql -n 100 --no-pager
sudo tail -n 100 /var/log/mysql/error.log 2>/dev/null在数据库中查看业务表定义和引擎：
SHOW TABLE STATUS FROM appdb LIKE 'orders'\G
SHOW CREATE TABLE appdb.orders\G
SELECT VERSION();如果错误表名类似 #sql... 或只在排序、GROUP BY、DISTINCT、UNION、CTE等查询中出现，可能是内部临时表；如果明确是业务表，则重点检查它所在的InnoDB表空间或其他引擎限制。
错误1114只描述当前存储对象无法继续扩展，不能单凭报错文字确定根因。
检查MySQL实际使用的文件系统
不要只运行一次 df -h /。先读取关键目录，再分别检查容量、inode和挂载属性：
SHOW VARIABLES WHERE Variable_name IN
('datadir','tmpdir','innodb_data_file_path','innodb_temp_data_file_path');df -hT /var/lib/mysql /tmp
df -i /var/lib/mysql /tmp
findmnt -T /var/lib/mysql
findmnt -T /tmp实际路径应以查询结果为准。容器内还要检查宿主机卷、overlay存储和容器配额；云盘可能有独立容量上限。容量充足但inode耗尽、文件系统只读或项目配额已满，同样会阻止表空间和临时文件增长。
区分InnoDB表空间与业务表问题
MySQL 8.4错误参考说明，InnoDB在系统表空间没有可用空间时会报告1114。检查表是否使用独立表空间以及系统表空间配置：
SELECT NAME, SPACE_TYPE, FILE_SIZE, ALLOCATED_SIZE
FROM INFORMATION_SCHEMA.INNODB_TABLESPACES
ORDER BY ALLOCATED_SIZE DESC
LIMIT 20;
SHOW VARIABLES LIKE 'innodb_file_per_table';
SHOW VARIABLES LIKE 'innodb_data_file_path';如果系统表空间文件被配置为固定大小且不能自动扩展，应先备份并按官方表空间流程规划扩容或迁移。不要在MySQL运行时手工删除、截断或替换ibdata文件。 对独立表空间，确认数据盘空间、表定义和分区上限，再决定归档、扩盘或在线DDL。
涉及大表变更时先评估临时空间和额外副本需求，维护窗口内保留可验证的备份与回滚方案。
临时表满了该查哪些变量
MySQL 8.4中，tmp_table_size 限制单个内存内部临时表；达到限制后，TempTable会转换为磁盘上的InnoDB内部临时表。全局TempTable资源还受 temptable_max_ram 和 temptable_max_mmap 控制。
SHOW VARIABLES WHERE Variable_name IN
('tmp_table_size','temptable_max_ram','temptable_max_mmap','tmpdir');
SHOW GLOBAL STATUS WHERE Variable_name IN
('Created_tmp_tables','Created_tmp_disk_tables');把tmp_table_size大幅调高并不等于消除磁盘临时表，还可能放大并发查询的内存压力。 应结合执行计划减少无界排序、过宽行和不必要的中间结果，并确保tmpdir所在文件系统有足够空间。
需要压测表空间增长，可在 萤光云 创建隔离数据库节点；要对比不同磁盘规格下的临时表行为，也可在 LightNode 部署临时环境。不要用生产全量数据和真实访问凭据做实验。
按根因处理并完成验收
根因不同，处理方向也不同：文件系统容量不足就先释放非数据库垃圾或扩盘；inode、配额和只读挂载要修对应资源；固定系统表空间要按官方流程扩展；MEMORY表则检查 max_heap_table_size 和表的用途；内部临时表应同时优化SQL与临时空间。
修复后重新执行最小化的失败操作，并观察错误日志、磁盘和临时表计数。对生产DDL或大批量写入，先在副本或测试环境验证所需空间，不要反复重试同一条可能持续占用临时空间的语句。
验收标准应包括1114不再出现、目标文件系统与表空间仍有安全余量、MySQL错误日志没有新的I/O错误，并且业务查询结果和数据一致性正常。
FAQ
根分区有空间，为什么仍然说table is full？
MySQL的数据目录、tmpdir或容器卷可能位于其他文件系统；也可能是inode、配额、固定表空间或特定引擎上限，而非根分区容量。
直接增大tmp_table_size可以吗？
不能作为通用修复。它只影响单个内存内部临时表的限制，并会改变内存风险；达到条件后仍可能转为磁盘临时表。
可以删除ibdata或ibtmp文件腾空间吗？
不能在运行中的生产库随意删除。系统表空间承载持久数据；临时表空间也应由MySQL按受支持流程管理，错误删除可能导致实例无法启动。
温馨提示
错误1114是资源边界信号，而不是单一磁盘告警。先按对象、引擎和真实路径定位，再扩容或调参；任何表空间文件操作都必须以有效备份、官方流程和维护窗口为前提。
