MySQL报错“The table 'wind_spe_dir' is full”常见原因有哪些？

Question

MySQL报错“The table 'wind_spe_dir' is full”并非指数据量超出表定义上限，而是典型的空间资源耗尽告警。常见原因包括：① **磁盘空间不足**——数据文件所在分区（如 `/var/lib/mysql`）被写满；② **InnoDB 表空间配额超限**——若启用了 `innodb_file_per_table=OFF` 且系统表空间（ibdata1）已满，或启用了 `innodb_data_file_path` 限制了总大小；③ **临时表空间爆满**——大排序、GROUP BY 或 JOIN 操作生成巨量临时数据，超出 `tmp_table_size` / `max_heap_table_size`（内存临时表）或磁盘临时目录（如 `/tmp`）容量；④ **分区表单一分区填满**——若 `wind_spe_dir` 是分区表，某分区对应的数据文件所在路径空间不足；⑤ **操作系统级限制**——如 inode 耗尽、SELinux/AppArmor 阻止写入、或挂载选项含 `noexec,nosuid,nodev` 影响临时文件创建。排查需结合 `df -h`、`du -sh /var/lib/mysql/*`、`SHOW TABLE STATUS LIKE 'wind_spe_dir'` 及错误日志中的具体 errno（如 Errno 28 = No space left on device）。

Answer 1

```html

一、现象定位：从错误表象到本质诊断

MySQL 报错 The table 'wind_spe_dir' is full 是极具迷惑性的“伪容量错误”——它不表示该表行数或单行大小突破了 InnoDB 逻辑上限（如 64TB 表空间限制），而是 MySQL 内核在尝试分配新页、写入临时段或扩展数据文件时，底层 I/O 层返回失败（典型 errno 28: No space left on device）。该错误本质是资源链路中任一环节的物理/配额瓶颈被击穿，需跳出 SQL 层，深入 OS→存储→MySQL 配置三级协同分析。

二、五维根因矩阵：系统化归因框架

维度	核心机制	关键验证命令	高危信号
① 磁盘空间不足	/var/lib/mysql 所在挂载点满载，InnoDB 无法追加 ibd 或 ib_logfile	df -h /var/lib/mysql; df -i /var/lib/mysql	Use% ≥95% 或 Inodes% = 100%
② InnoDB 系统表空间耗尽	innodb_file_per_table=OFF 时所有表共享 ibdata1；其大小由 innodb_data_file_path=ibdata1:12M:autoextend:max:2G 硬限制	ls -lh /var/lib/mysql/ibdata1; SHOW VARIABLES LIKE 'innodb_data_file_path';	ibdata1 文件已达 max: 上限且无 autoextend 权限
③ 临时表空间崩溃	大查询触发磁盘临时表（tmpdir=/tmp），而 /tmp 分区仅 1GB 且被日志占满	SHOW VARIABLES LIKE 'tmpdir'; df -h $(mysql -Nse "SELECT @@tmpdir")	Created_tmp_disk_tables / Created_tmp_tables > 0.3（监控指标）

三、深度排查路径：从 OS 到 MySQL 内核的穿透式验证

1. OS 层快照：执行 df -hT /var/lib/mysql /tmp 获取文件系统类型与剩余空间；用 lsof +L1 检查被删除但未释放句柄的大文件
2. MySQL 元数据取证：运行 SHOW CREATE TABLE wind_spe_dir\G 确认是否为 PARTITION BY RANGE 表；若为分区表，执行 SELECT PARTITION_NAME, TABLE_ROWS, DATA_LENGTH FROM INFORMATION_SCHEMA.PARTITIONS WHERE TABLE_NAME='wind_spe_dir'
3. InnoDB 表空间审计：对 wind_spe_dir 执行 SHOW TABLE STATUS LIKE 'wind_spe_dir'\G，重点观察 Data_length（实际数据页）、Index_length（索引页）及 Data_free（空闲页，若为 0 且 innodb_file_per_table=ON，则 ibd 文件已物理写满）
4. 错误日志精读：在 /var/log/mysql/error.log 中搜索 wind_spe_dir.*full，提取完整堆栈及 errno，例如：InnoDB: Error number 28 means 'No space left on device'

四、解决方案全景图：按风险等级分级处置

graph LR
A[紧急止血] --> B[清理磁盘临时文件]
A --> C[重启 MySQL 释放 tmpdir 占用]
D[中期治理] --> E[迁移 tmpdir 至大容量分区]
D --> F[启用 innodb_file_per_table=ON 并重建表]
G[长期架构] --> H[分区表按时间轮转+冷热分离]
G --> I[部署 Prometheus+mysqld_exporter 监控 Data_free & tmp_disk_tables]

五、高阶避坑指南：五年以上 DBA 必知的隐性陷阱

• SELinux 的静默拦截：当 setenforce 1 且 MySQL 的 tmpdir 设为 /mnt/data/tmp 时，SELinux 可能拒绝 mysqld_t 域写入，需执行 semanage fcontext -a -t mysqld_tmp_t "/mnt/data/tmp(/.*)?"; restorecon -Rv /mnt/data/tmp
• ext4 文件系统 inode 耗尽：小文件密集型场景（如每行存 1KB JSON），df -i 显示 inode 用尽，但 df -h 仅 40% 空间占用，此时需重建文件系统并指定 -i 16384（每 16KB 一个 inode）
• docker 容器的 tmpfs 限制：Kubernetes Pod 中 emptyDir: {medium: Memory} 默认仅 512MB，超出后 MySQL 创建 MEMORY 临时表失败，报 same error —— 需显式设置 sizeLimit: 2Gi
• 云盘的 IOPS 瓶颈伪装：AWS gp3 卷在突发 IOPS 耗尽后，写入延迟飙升至秒级，MySQL 认为“写入超时即空间满”，需结合 iostat -x 1 观察 %util 与 await

```