“The table is full”并非单一原因，实际可能源于MEMORY表内存超限、tmp_table_size/max_heap_table_size不足、临时表写满磁盘，或InnoDB数据文件、归档日志所在分区空间耗尽。
MySQL报“The table is full”到底是因为内存不够还是磁盘满了？
这个错误不是单一原因，The table is full 在 MySQL 中是“通用占位符”，实际背后可能是 MEMORY 表爆内存、tmp_table_size 或 max_heap_table_size 不足、临时表写满磁盘，甚至 InnoDB 数据文件（ibdata1）或归档日志（ib_logfile）所在分区空间耗尽。先别急着扩容磁盘——得先定位真实瓶颈。
查清到底是哪类“满”：从 error log 和状态变量入手
直接看 MySQL 错误日志（通常是 /var/log/mysql/error.log 或 SHOW VARIABLES LIKE 'log_error';），里面常带更具体的线索，比如：
• 出现 ERROR 1114 (HY000): The table 'xxx' is full 且表引擎是 MEMORY → 内存超限
• 出现 Could not create temporary file 或 write failed: No space left on device → 磁盘满（注意：不一定是数据目录，也可能是 tmpdir 所在分区）
• 执行 SHOW GLOBAL STATUS LIKE 'Created_tmp%';，若 Created_tmp_disk_tables 持续增长，说明频繁落地临时表，tmp_table_size 和 max_heap_table_size 可能设太小
• 运行 df -h 查所有挂载点，重点盯 tmpdir（SHOW VARIABLES LIKE 'tmpdir';）、datadir、innodb_log_group_home_dir
MEMORY 表爆了怎么办？不能只调大 max_heap_table_size
MEMORY 表数据全在内存里，max_heap_table_size 是单表上限，但它的值还受 tmp_table_size 影响（两者取小者）。盲目调高可能引发 OOM，尤其当多个会话并发建大 MEMORY 表时。
• 检查当前设置：SHOW VARIABLES LIKE 'max_heap_table_size'; 和 SHOW VARIABLES LIKE 'tmp_table_size';
• 如果确认是业务误用 MEMORY 存大量数据，优先改用 InnoDB 表 —— 它支持磁盘回退，不会突然报 “table is full”
• 若必须用 MEMORY，建议将 max_heap_table_size 设为略高于单表最大预期体积，并监控 SHOW TABLE STATUS LIKE 'xxx'; 中的 Data_length
• 注意：该变量是会话级生效的，全局修改需写入配置文件并重启，或用 SET GLOBAL（需 SUPER 权限）
磁盘空间不足时，哪些路径最容易被忽略？
很多人只查 datadir，却忘了 MySQL 有多个“落盘”出口：
• tmpdir：排序、GROUP BY、子查询等产生的内部临时表默认写这里，Linux 下常是 /tmp，容易被其他进程塞满
• slow_query_log_file 和 general_log_file：开启日志后，日志文件可能暴涨（尤其 general_log）
• relay_log 和 master-info-file：主从环境中，中继日志堆积在从库 relay_log_basename 目录下
• innodb_undo_directory：如果单独配置了 undo 表空间路径，它所在的分区也可能满
• /var/run/mysqld/（socket 文件目录）：虽小，但在某些容器或精简系统中空间极小，也会触发类似报错
清理前先用 lsof +L1 查是否有已删除但仍被 mysqld 占用的大文件（常见于未轮转的日志）
df -h 确认。 
