“No space left on device”（错误28）本质是挂载点空间或inode耗尽，需用df -h和df -i分别检查Use%与IUse%≥95%的分区，重点排查/var/lib/mysql、/tmp、/var/log等路径所在挂载点，并确认MySQL实际tmpdir位置，避免误删关键文件。
查清到底是哪个挂载点满了
Got error 28 不是 MySQL 自己出的错，是操作系统返回的 ENOSPC（No space left on device）。df -h 输出里 Use% ≥95% 的行都要盯紧，尤其关注这些路径所在的设备：
-
/var/lib/mysql（data 目录） -
/tmp（注意：可能是tmpfs，只占内存一半） -
/var/log（慢日志、错误日志堆积） -
/var/lib/mysql/binlog或/var/lib/mysql/relaylog
别只看根分区——/var 单独挂载且 100%，/ 还有空间，照样报 28。
确认 MySQL 实际用的 tmpdir 路径
别默认删 /tmp。执行：mysql -Nse "SELECT @@tmpdir"
返回值才是真实路径。常见陷阱：
- 输出是
/var/tmp，但/var分区只剩 2%，删/tmp没用 - 输出是
/run/mysqld，这是 tmpfs，重启后自动清空，但运行中占满就卡死 - 输出为空？说明 MySQL 继承了启动时的
TMPDIR环境变量，查ps aux | grep mysqld
临时文件名通常带 #sql_、SQL_、MYD_ 前缀；mysql.sock、ibtmp1、aria_log. 这些不能碰。
MySQL8 CRM Schema Design Expert
下载
面向 CRM 系统的 MySQL 8 数据库模式设计。当用户需要为客户关系管理（CRM）系统设计、评审、优化或生成数据库模式时，应使用此项技能。
清理被进程占用却已标记 deleted 的文件
执行 lsof +L1 或 lsof | grep -i 'deleted' | grep mysql，如果看到类似：/tmp/#sql_abc123.MYD (deleted)
说明文件已删，但 MySQL 进程还拿着句柄，磁盘空间不释放。
- 最稳妥：重启 MySQL（
systemctl restart mysqld） - 无法重启时，可尝试 kill 对应连接 ID，但效果不确定
- 别直接
rm -rf /tmp/*——可能干掉mysql.sock或 systemd 临时文件，导致服务起不来
安全清理命令（只删 1 小时前的 MySQL 临时表）：find $(mysql -Nse "SELECT @@tmpdir") -name "#sql_*" -mmin +60 -delete
改 tmpdir 必须停服务+配文件+重启
tmpdir 是只读启动参数，SET GLOBAL tmpdir = '/new' 会报错。必须：
- 停 MySQL：
systemctl stop mysqld - 新建目录，确保属主为
mysql:mysql，权限750，文件系统为ext4或xfs（NFS/overlayfs 不稳定） - 修改
/etc/my.cnf的[mysqld]段：tmpdir = /mnt/big-disk/mysql-tmp - 重启后立刻验证：
mysql -e "SHOW VARIABLES LIKE 'tmpdir'"+ls -ld /mnt/big-disk/mysql-tmp
真正容易被忽略的是：tmpdir 支持多路径轮询（用 : 分隔），但若第一个路径所在挂载点爆满，MySQL 仍会卡在写入阶段报 28，不会自动 fallback 到下一个——它只按顺序试一次。
