错误1114并非表数据量达极限，而是tmpdir磁盘空间不足或InnoDB表空间（如ibdata1）配置不当（如未启用autoextend）导致；需检查磁盘剩余、长事务、大字段及配置参数。
MySQL错误1114：The table is full 是表空间真的满了？
错误1114表面看是“表满了”，但实际绝大多数情况和“磁盘空间”或“InnoDB表空间配置”有关，而非数据量真达到极限。它常出现在INSERT、UPDATE或ALTER TABLE操作时，尤其在写入大BLOB/TEXT字段、执行大事务或临时排序/聚合时触发。
常见诱因：tmpdir不足、innodb_data_file_path配错、ibdata1不可扩展
MySQL内部会用临时文件（如排序、GROUP BY、CREATE TEMPORARY TABLE）或InnoDB系统表空间（ibdata1）存放元数据和undo日志。若tmpdir所在分区满，或innodb_data_file_path设为固定大小且autoextend未启用，就会报1114。
-
tmpdir路径可通过SHOW VARIABLES LIKE 'tmpdir';查，确保其挂载点剩余空间 ≥ 最大单条SQL可能生成的临时数据量（例如大JOIN结果集） -
innodb_data_file_path若设为ibdata1:12M:autoextend才允许增长；若写成ibdata1:512M（无:autoextend），一旦用完就无法再写入新undo记录 - 使用
innodb_file_per_table=OFF时，所有表数据都挤在ibdata1里，极易撑爆——这是老配置遗留的高危模式
快速诊断：查磁盘、查表空间状态、查事务大小
先别急着删数据，按顺序确认瓶颈点：
- 运行
df -h看tmpdir和datadir所在分区是否 ≥ 15% 剩余空间 - 执行
SELECT FILE_NAME, TABLESPACE_NAME, ENGINE, TOTAL_EXTENTS * EXTENT_SIZE AS SIZE_BYTES FROM INFORMATION_SCHEMA.FILES WHERE FILE_TYPE = 'DATAFILE';看ibdata1是否已到上限 - 检查长事务：
SELECT * FROM INFORMATION_SCHEMA.INNODB_TRX ORDER BY TRX_STARTED LIMIT 5;——未提交的大事务会持续占用undo空间，导致1114 - 对出问题的表执行
SHOW CREATE TABLE `xxx`;，确认是否含超大TEXT/BLOB字段，这类字段默认走ibdata1存储（即使innodb_file_per_table=ON）
修复与规避：改配置、清事务、拆大字段
临时救急和长期治理要分开做：
- 立即释放空间：杀掉长时间运行的事务（
KILL），清理trx_mysql_thread_id;/tmp下残留的#sql_*临时文件 - 重启前修改
my.cnf：给innodb_data_file_path加上:autoextend:max:2G（根据磁盘余量设合理上限），并确保innodb_file_per_table=ON - 对含大字段的表，考虑拆分：把
TEXT列移到单独的关联表，主表只存ID；或改用外部存储（如OSS/S3）+ URL字段 - 避免在OLTP场景用
ORDER BY RAND()、全表GROUP BY等易触发大临时表的操作
真正麻烦的是ibdata1已满且无法收缩——它不像独立表空间能直接TRUNCATE。这时候要么导出重建，要么接受它永远占着那块空间。很多人卡在这一步，不是不会修，是没意识到ibdata1的膨胀是单向的。
