“the table is full”通常指mysql临时表超出内存或磁盘限制；90%情况需同步调高tmp_table_size和max_heap_table_size至相同值，因mysql取二者较小值作为内存临时表上限，若仅调高其一仍会强制落盘，进而因磁盘空间或权限不足报错。
“The table is full”不是表真满了，而是MySQL临时表撑爆了内存或磁盘空间——90%的情况只需同步调高 tmp_table_size 和 max_heap_table_size，且必须设为相同值。
为什么改了 tmp_table_size 还报错？
因为MySQL实际取 tmp_table_size 和 max_heap_table_size 中的较小值作为内存临时表上限。比如你只改了 tmp_table_size = 512M，但 max_heap_table_size 还是默认的 16M，那临时表最多只能用 16MB，一超就强制写磁盘；如果磁盘上又没权限/空间写临时文件（比如 /tmp 满了），就会直接报错。
- 必须同时设置两个参数，且值完全一致（如都设为
256M） - 会话级修改只对当前连接生效：
SET SESSION tmp_table_size = 268435456;、SET SESSION max_heap_table_size = 268435456; - 全局生效需改配置文件，在
[mysqld]下加两行：tmp_table_size = 256M和max_heap_table_size = 256M，然后重启 MySQL - 注意单位：MySQL 配置中不识别
MB或GB，写256M可以，但256MB无效；2G合法，2048M也合法
查清到底是内存撑爆还是磁盘撑爆
先别急着改参数，得确认瓶颈在哪。错误日志和状态变量能给出关键线索：
- 看错误日志（路径由
SHOW VARIABLES LIKE 'log_error';查）：如果出现Could not create temporary file或No space left on device，基本是磁盘问题 - 执行
SHOW GLOBAL STATUS LIKE 'Created_tmp%';：若Created_tmp_disk_tables持续增长，说明频繁落地磁盘临时表，tmp_table_size太小 - 查 MySQL 用的临时目录：
SELECT @@tmpdir;，然后运行df -h /tmp（或对应路径）看磁盘使用率 - 查数据目录所在分区：
SHOW VARIABLES LIKE 'datadir';，再df -h看是否接近 100%
RDS 或云数据库遇到 #tab_name 是 full 怎么办
阿里云 RDS 等托管服务会额外限制磁盘临时表总大小，报错里带路径如 /home/mysql/xxx/#tab_name，说明已触达 loose_rds_max_tmp_disk_space 上限（默认 10GB）。
- 该参数单位是字节，
10737418240= 10GB，最大可设到107374182400（100GB） - 在控制台参数管理中直接修改，无需重启实例
- 但不能无脑拉满：要留出至少 10%~20% 空间给 binlog、错误日志等系统文件，否则可能触发实例锁定
- 配合调高
tmp_table_size（RDS 中上限 64MB），减少落地磁盘的频率
MEMORY 表自己报 “The table is full” 怎么办
如果你建的是 ENGINE=MEMORY 的表，并在插入或查询时遇到这个错误，那不是临时表的问题，是这张表本身内存超限了。
- 查表实际大小：
SHOW TABLE STATUS LIKE 'your_table_name';，看Data_length - 查当前上限：
SHOW VARIABLES LIKE 'max_heap_table_size';，如果Data_length接近或超过它，就是真满了 - 临时救急可用会话级设置：
SET SESSION max_heap_table_size = 536870912;（512MB），再执行INSERT或ALTER TABLE ... ENGINE=InnoDB; - 长期方案：别用
MEMORY存业务主表——它不支持磁盘回退，OOM 风险高；改用InnoDB，自动溢出，更稳
真正容易被忽略的是：同一个错误，背后可能是内存参数、磁盘空间、云厂商配额、甚至已删除但未释放句柄的大文件——必须按顺序排查，不能只盯着配置文件改数字。
