MySQL安装报“No space left on device”90%是/tmp或/var/tmp分区小或被tmpfs限制，需用df和lsof定位并迁移TMPDIR、datadir及tmpdir至大分区。
MySQL安装失败报“No space left on device”，90%以上不是磁盘真没空间，而是/tmp或/var/tmp所在分区太小，或安装器临时解压路径被卡死。
为什么安装时突然爆满 /tmp？
MySQL 安装包（deb/rpm）本身不大，但安装过程要解压、初始化系统表、生成 ibdata1/ib_logfile*、写 binlog 等，中间大量依赖临时目录。默认行为如下：
Debian/Ubuntu 的
默认用
解压 deb 包，再拷贝到目标路径；
CentOS/RHEL 的
或
默认走
，且
可确认；
源码编译时，
若未指定
，可能落在
，而该分区常较小；
很多云主机或容器环境的
是
（内存挂载），大小仅为 RAM 的一半，几 GB 就撑爆。
怎么快速定位是哪个分区在拖后腿？
别猜，直接执行这三行命令：
重点关注输出中
≥95% 的挂载点。特别注意：
显示为
类型时，容量就是硬上限，删文件也无效——必须换路径。
MySQL（Linux）
MySQL 9.6.0是面向Linux平台的2026年创新版本，核心架构迎来重大革新。其将外键约束与级联操作从InnoDB引擎层上移至SQL层，确保所有数据变更均被完整记录至Binlog，彻底解决了CDC（变更数据捕获）与主从复制中的数据不一致难题。此外，该版本引入container_aware启动选项以原生适配容器环境，并对审计日志进行了组件化重构，为追求极致数据一致性与云原生体验的开发者提供了全新选择。
下载
不重装、不扩容，立刻绕过限制的实操方法
核心思路：把安装器和 MySQL 启动时的临时落脚点，挪到有空间的地方。
安装前设置环境变量：
（确保该目录存在、权限为
、且不在
上）；
APT 安装时强制指定临时目录：
；
RPM 安装前建软链（慎用）：
，但需在
执行前完成，且重启后可能失效；
安装完成后**必须立刻改配置**：编辑
，在
下加：
，然后迁移数据、同步权限、检查
systemd 保护项是否拦住了新路径。
清理 /tmp 里残留的 MySQL 临时文件（安装失败后）
安装中断后，
下可能留着
、
、
碎片等，它们不显示在普通
中（因被进程占用或已删未释放）。
先查“幽灵文件”：
或
；
确认无活跃 MySQL 进程后再清理：
；
不要
—— 会误删
、
等关键文件，导致后续服务起不来；
不在
，而在
下，它不能手动删除非停服，且删完必须重启 MySQL 才重建。
真正麻烦的从来不是空间本身，而是 tmpdir 和 datadir 路径混用、权限错配、或 systemd 沙箱限制了新路径访问——这些不会报错，但会让 MySQL 启动失败，且日志里只字不提。
apt/tmpyumrpm/var/tmprpm --showrc | grep tmpcmake-DCMAKE_INSTALL_PREFIX/usr/local/tmptmpfsdf -h | grep -E '(tmp|var|usr)'
df -h $(dirname $(mysql -Nse "SELECT @@datadir" 2>/dev/null || echo "/var/lib/mysql"))
ls -ld /tmp /var/tmpUse%/tmptmpfsexport TMPDIR=/data/tmpmysql:mysqltmpfssudo apt -o DPkg::Install::TempDir=/data/tmp install mysql-serversudo ln -sf /data/tmp /var/tmprpm/etc/mysql/my.cnf[mysqld]datadir = /data/mysql
tmpdir = /data/mysql-tmpProtectHome/tmp#sql_*mysql_install_db.*ibtmp1lslsof +L1lsof | grep deletedsudo find /tmp -name "#sql_*" -mmin +30 -deleterm -rf /tmp/*systemd-private-*.tmpmysql.sockibtmp1/tmpdatadir