“the table is full”错误90%与业务表无关，实为tmp_table_size和max_heap_table_size取小值过低导致内存临时表溢出，或tmpdir/datadir磁盘空间、inode耗尽；须同步调两参数至相同值（如256m），并检查错误日志、df -h各关键路径及lsof删除文件句柄。
查清到底是哪张“表”满了
错误里写的 canteen_membership 或 sys_dict 只是触发点，不是真凶。MySQL 报 “The table is full” 时，90% 的情况跟这张业务表本身无关，而是临时表、内存表或磁盘空间撑不住了。
先确认引擎类型：SELECT table_name, engine FROM information_schema.tables WHERE table_name = 'canteen_membership';。如果是 MEMORY 引擎，那真是内存不够；如果是 InnoDB 或 MyISAM，就别急着扩表，往下查。
- 执行
SHOW VARIABLES LIKE 'log_error';找到错误日志路径，用tail -n 50 /var/log/mysql/error.log看有没有No space left on device或Could not create temporary file - 运行
df -h，重点盯datadir（SHOW VARIABLES LIKE 'datadir';）、tmpdir（SELECT @@tmpdir;）和innodb_log_group_home_dir所在分区 - 如果
df -h显示满，但du -sh /var/lib/mysql总和远小于该分区容量，大概率是lsof | grep deleted | grep mysql找出被删未释放的文件句柄
tmp_table_size 和 max_heap_table_size 必须设成一样
这两个参数不是“可选配”，是硬性协同项：MySQL 实际取二者中较小值作为内存临时表上限。只改 tmp_table_size = 256M 而 max_heap_table_size 还是默认 16M，等于没改——临时表一超 16MB 就强制落盘，再碰上 /tmp 满或没写权限，立刻报错。
MySQL 9.6.0是面向Linux平台的2026年创新版本，核心架构迎来重大革新。其将外键约束与级联操作从InnoDB引擎层上移至SQL层，确保所有数据变更均被完整记录至Binlog，彻底解决了CDC（变更数据捕获）与主从复制中的数据不一致难题。此外，该版本引入container_aware启动选项以原生适配容器环境，并对审计日志进行了组件化重构，为追求极致数据一致性与云原生体验的开发者提供了全新选择。
- 会话级临时生效：
SET SESSION tmp_table_size = 268435456;和SET SESSION max_heap_table_size = 268435456; - 全局生效必须改配置文件，在
[mysqld]下加两行：tmp_table_size = 256M和max_heap_table_size = 256M，然后重启 MySQL - 单位只认
M或G，256MB或256m都无效；数值建议不超过物理内存的 10%～15%，避免挤占innodb_buffer_pool_size
tmpdir 所在分区可能比 datadir 更早爆掉
很多人只盯着 /var/lib/mysql，却忘了 MySQL 默认把排序、GROUP BY、子查询产生的临时表往 /tmp 写。而 /tmp 常被其他进程（比如 Tomcat 日志、CI 构建缓存）塞满，甚至挂载了 noexec 选项导致 MySQL 根本写不进去。
- 查当前临时目录：
SELECT @@tmpdir;，然后立刻执行df -h /tmp和df -i /tmp（inode 耗尽也会报错） - 清理
/tmp下过期临时文件：find /tmp -name "*.tmp" -type f -mtime +7 -delete（执行前先ls -lt /tmp/*.tmp | head -10确认） - 长期方案：在 my.cnf 中指定大分区路径，例如
tmpdir = /data/tmp，并确保mysql用户对该目录有读写权限
MEMORY 表真满了不能只调参数
如果报错明确指向一张 ENGINE=MEMORY 表（比如 ERROR 1114: The table 'session_cache' is full），那就是内存真撞墙了。这种表不支持磁盘回退，max_heap_table_size 就是它的绝对上限。
- 查这张表实际用了多少：
SHOW TABLE STATUS LIKE 'session_cache';看Data_length是否接近max_heap_table_size - 会话级救急：
SET SESSION max_heap_table_size = 536870912;（512M），再试 INSERT - 根本解法：别用
MEMORY存业务数据——改成ENGINE=InnoDB，它能自动溢出到磁盘，不会突然中断
最常被忽略的是：同一个错误，可能在不同时间由不同原因触发。今天是 /tmp inode 耗尽，明天可能是 ibdata1 在 innodb_file_per_table=OFF 下持续膨胀。每次遇到，都得重新走一遍定位链，而不是复用上次的“解决方案”。
