DDL中断主因是tmpdir、innodb_online_alter_log_max_size或数据目录三者之一空间不足，错误提示常误导定位；需依次检查tmpdir路径、日志缓冲大小及数据目录剩余空间。
直接说结论：DDL中断不是因为“磁盘真满了”，而是tmpdir、innodb_online_alter_log_max_size或数据目录本身三处之一空间不够，且错误提示往往指向错误位置——比如报The table '#sql-xxx' is full，实际却是/tmp只剩100MB。
确认到底是哪块空间卡住了
别靠猜，先查清楚。MySQL DDL失败时，错误信息极具误导性：
-
ERROR 1878 (HY000): Temporary file write failure→ 100%是tmpdir路径写失败，和数据目录无关 -
DB_ONLINE_LOG_TOO_BIG→innodb_online_alter_log_max_size被撑爆，不是磁盘满，是并发DML日志超限 -
ERROR 1114 (HY000): The table 'xxx' is full→ 多数情况仍是tmpdir不足，少数是数据目录没给中间表留够空间（需预留≈原表大小）
立刻执行这两条命令：
SELECT @@tmpdir, @@innodb_tmpdir;
SHOW VARIABLES LIKE 'innodb_online_alter_log_max_size';
再登系统终端，分别检查：df -h /tmp（或你查到的tmpdir路径）、df -h /var/lib/mysql（数据目录）、df -i /tmp（小文件多时inode可能先耗尽）。
临时排序文件爆tmpdir：最常见原因
ADD INDEX、MODIFY COLUMN、ENGINE=InnoDB这类操作会在tmpdir生成GB级排序文件。默认/tmp常是tmpfs内存挂载，仅1–2GB，远不够处理大表。
- 运行
df -T /tmp，若显示tmpfs类型，说明它受限于内存，不是物理磁盘 -
SET GLOBAL tmpdir不生效，必须改my.cnf并重启：tmpdir = /data/mysql-tmp - 确保新路径存在、MySQL进程用户（如
mysql）有读写权限，且不要放在NFS或低IO路径上 - 应急时可清
/tmp下#sql-开头的残留文件，但必须确认无活跃DDL（SHOW PROCESSLIST无alter状态）
innodb_online_alter_log_max_size不够：高并发下的隐形炸弹
这个参数控制Online DDL期间记录并发DML的日志缓冲上限，默认128MB。它不是磁盘配额，但一旦超限，MySQL会直接中止DDL并回滚未提交的DML，报错DB_ONLINE_LOG_TOO_BIG。
- 调大前先观察：在业务低峰期执行
ALTER TABLE t ADD INDEX(...)，同时监控SHOW ENGINE INNODB STATUS\G里的Online DDL log大小 - 安全值参考：对日均写入10万行的表，建议设为512MB；写入量翻倍，该值也需翻倍
- 修改方式：在
my.cnf加innodb_online_alter_log_max_size = 524288000（单位字节），重启生效 - 注意：该参数只影响日志缓冲，不解决
tmpdir空间问题，两者常需同时调优
中间表占满数据目录：容易被忽略的硬需求
重建类DDL（如ENGINE=InnoDB、MODIFY COLUMN）会在数据目录生成#sql-ibxxx.ibd中间表，大小≈原表。若数据目录只剩20%空间，而原表占30%，操作必然失败。
- 不能靠
information_schema.TABLES.DATA_LENGTH估算——它比真实.ibd文件小20%–30% - 真正要算的是：
du -sh /var/lib/mysql/dbname/tablename.ibd，再乘1.3作为安全余量 - 临时救急：用
mysqldump导出+DROP TABLE+重建导入，虽停机但可控；长期方案是提前规划扩容或分库分表 - 切记：
innodb_file_per_table=ON必须开启，否则所有表共用ibdata1，删表也不释放空间
真正麻烦的从来不是空间本身，而是三处空间需求（tmpdir、日志缓冲、中间表）彼此独立又相互耦合，一个没盯住就中断。运维脚本里最好把这三项检查全加上，而不是等报错再救火。
