ALTER TABLE报“The table '#sql-xxx' is full”主因是tmpdir磁盘或inode不足、或innodb_online_alter_log_max_size被并发DML日志撑爆，而非datadir空间不足；需查@@tmpdir、df -h/-i对应路径及该变量值。
ALTER TABLE报“The table '#sql-xxx' is full”到底卡在哪
错误提示本身极具误导性——它几乎从不表示数据目录（datadir）满了，而是指向tmpdir或innodb_online_alter_log_max_size不足。真正要盯的是这三处：tmpdir路径的磁盘空间、该路径的inode是否耗尽、以及innodb_online_alter_log_max_size值是否被并发DML日志撑爆。
- 运行
SELECT @@tmpdir, @@innodb_tmpdir;确认MySQL实际用哪个路径存临时文件（多数情况返回/tmp） - 立刻执行
df -h /tmp和df -i /tmp——若/tmp是tmpfs类型（df -T /tmp可验证），那它的大小受限于内存，不是物理磁盘，1–2GB很常见 - 查
SHOW VARIABLES LIKE 'innodb_online_alter_log_max_size';，默认128MB；如果DDL期间有大量UPDATE/INSERT并发，日志极易超限，触发DB_ONLINE_LOG_TOO_BIG并中止操作
正在执行的ALTER能直接KILL吗
可以KILL，但必须分清状态：在SHOW PROCESSLIST里看到状态是altering table或copy to tmp table，说明DDL已进入物理阶段，此时KILL会触发回滚，而回滚本身也要写日志、占空间、耗时间——可能比让它跑完还慢。
- 优先检查
tmpdir是否真满：如果df -h显示剩余 - 确认无其他活跃DDL：
SHOW PROCESSLIST里没有其它alter或copy状态，再KILL目标线程，避免锁竞争加剧 - KILL后立即查
ls -lh /tmp/#sql-*，若有残留临时文件，且确认无任何ALTER在运行，才可手动rm（否则可能损坏正在进行的其它操作）
如何安全取消并防止再次发生
取消只是应急，真正要堵住源头。关键不是调大某个参数，而是让MySQL知道“哪里能写、写多少、写多久”。
-
tmpdir必须改到真实磁盘路径：在my.cnf里设tmpdir = /data/mysql-tmp，确保该目录存在、属主为mysql用户、不在NFS或低IO设备上；SET GLOBAL tmpdir不生效，必须重启 - 调高
innodb_online_alter_log_max_size：对大表+高并发场景，设为512M或1G（单位字节），但别盲目堆大——它本质是内存缓冲区，过大可能挤占Buffer Pool - DDL前做空间预检：对>500MB的表，执行前先
df -h /data/mysql-tmp和df -h /var/lib/mysql，确保两者均>原表大小×1.5（中间表+排序文件+日志缓冲） - 替代方案更可控：如只需重建表释放碎片，用
ALTER TABLE t1 ENGINE=InnoDB;比MODIFY COLUMN更轻量；若字段变更不可避免，考虑pt-online-schema-change避开锁与临时空间高峰
最常被忽略的细节
很多人修完就走，但下次出问题还是同一位置。两个隐形陷阱必须处理：
-
tmpdir路径下残留的#sql-ib*或#sql-*文件，不是“死文件”，而是上次失败DDL留下的半成品，它们持续占用空间且不显示在du统计里，必须用lsof +L1 | grep /tmp确认是否被进程持有，再决定删或重启mysqld -
innodb_file_per_table=ON没开的话，ALTER TABLE ... ENGINE=InnoDB不会生成独立.ibd，所有表仍挤在ibdata1里，删表也不释放空间——这个配置必须在建库前就定好，运行中无法动态开启
