ERROR 1114 (HY000): The table 'xxx' is full 中的 xxx 可能是业务表、MySQL自动创建的临时表（如GROUP BY生成的）或MEMORY引擎表；需查错误日志定位具体类型，再结合df -h、lsof、SHOW VARIABLES和SHOW TABLE STATUS等命令分层排查磁盘、内存及表空间真实瓶颈。
查清报错到底指向哪张“表”
ERROR 1114 (HY000): The table 'xxx' is full 中的 xxx 很关键——它可能是你写的业务表名，也可能是 MySQL 自动创建的临时表（如 SELECT ... GROUP BY 产生的 ***），甚至可能是 MEMORY 引擎表名。别凭直觉猜，先看错误日志：tail -n 50 /var/log/mysql/error.log，重点找带 Could not create temporary file、No space left on device 或明确写出表引擎是 MEMORY 的行。
tmp_table_size 和 max_heap_table_size 必须设为相同值
这两个参数不是独立生效的：MySQL 实际允许的内存临时表大小，取的是 tmp_table_size 和 max_heap_table_size 中的较小值。哪怕你只改了 tmp_table_size = 2G，但 max_heap_table_size 还是默认 16M，那临时表一超 16M 就强制落磁盘——如果磁盘又没空间或没写权限，就直接报 “The table is full”。
- 会话级临时调整（仅当前连接有效）：
SET SESSION tmp_table_size = 268435456;和SET SESSION max_heap_table_size = 268435456; - 全局生效必须改配置文件，在
[mysqld]下加两行：tmp_table_size = 256M和max_heap_table_size = 256M - 单位注意：
M可用，MB无效；G要写成2G，不能写2GB
磁盘空间满才是最常被忽略的根因
80% 以上的 “The table is full” 其实和内存无关，而是磁盘写满。但要注意：不一定是 datadir 所在分区，更可能是 tmpdir（SHOW VARIABLES LIKE 'tmpdir'; 查）或 innodb_log_group_home_dir 所在挂载点。
- 先跑
df -h，盯住所有挂载点，尤其/tmp、/var/tmp、/home（很多 MySQL 迁移后数据目录放在那里） - 如果
df显示某分区 100%，但du -sh /path总和远小于此，说明有进程还占着已删除文件的句柄，用lsof | grep deleted找出并重启对应服务 - 别只盯着数据库文件——曾有案例是 Tomcat 的
catalina.out日志涨到 99GB，把整个/home分区撑爆
确认是不是 MEMORY 表真满了
如果你建的是 CREATE TABLE t ENGINE=MEMORY ...，那这个错误就是字面意思：这张表内存不够了。它不支持磁盘回退，max_heap_table_size 是单表硬上限，且受会话级设置影响。
- 查当前设置：
SHOW VARIABLES LIKE 'max_heap_table_size';和SHOW VARIABLES LIKE 'tmp_table_size'; - 查该表实际大小：
SHOW TABLE STATUS LIKE 't';看Data_length是否接近max_heap_table_size - 优先方案不是调大参数，而是改用
InnoDB表——它能自动落到磁盘，避免突发报错 - 若必须用
MEMORY，务必监控Created_tmp_tables和Created_tmp_disk_tables状态变量，持续高差值说明频繁落地，配置已失效
tmpdir 和 datadir 可能在不同分区，或者误以为 df -h 看了根目录就万事大吉。 
