必须用tmpfs而非/dev/ram0，因后者依赖未默认加载的brd模块、需手动格式化、刚性占用内存且易引发启动卡顿；tmpfs内核原生支持、无需模块、动态按需分配、支持swap回退，更可靠高效。
直接用 tmpfs + tmpdir 配合 systemd automount，不要碰 /dev/ram0 或手动写 init 脚本——后者既不可靠又难维护。
为什么必须用 tmpfs 而不是 /dev/ram0
现代 Linux 发行版默认不加载 brd 模块，/dev/ram0 设备节点往往根本不存在；即使手动 modprobe brd 成功，也要格式化、设权限、处理设备生成时机，稍有疏漏就导致 MySQL 启动失败或挂载卡住。而 tmpfs 是内核原生支持的内存文件系统，无需模块、无需格式化、动态按需分配内存（不写满就不占），还支持 swap 回退——这才是生产环境该用的方式。
-
tmpfs占用内存是弹性的：存 1KB 文件只占几 KB 页缓存，不是锁死整块内存 -
/dev/ram0是刚性块设备：分配 2G 就立刻锁定 2G 物理内存，哪怕空着 -
tmpfs可以直接挂载到任意路径（如/data/mysql_tmp），和 MySQL 的tmpdir天然契合
配置 tmpfs 自动挂载到 MySQL 临时目录
目标是让 /data/mysql_tmp 在首次被 MySQL 访问时自动挂载为 tmpfs，且开机即就绪。关键不是“挂上就行”，而是避免启动 race condition 和权限错配。
Linux Security Scanner
下载
Linux 安全审计工具，检查 SSH 配置、开放/监听端口、防火墙规则（ufw/iptables/nftables）、失败登录尝试、sudoers 权限...
- 先创建挂载点：
sudo mkdir -p /data/mysql_tmp - 写入
/etc/fstab（注意x-systemd.automount）：tmpfs /data/mysql_tmp tmpfs size=2G,mode=755,defaults,x-systemd.automount 0 0
-
mode=755必须带执行位（x），否则 MySQL 某些版本会因无法chdir报错；别用700或777 - 运行
sudo systemctl daemon-reload && sudo systemctl restart local-fs.target测试，或重启验证 - 确认生效：
findmnt -t tmpfs | grep mysql_tmp应显示挂载项及size=2G
MySQL 配置 tmpdir 指向该 Ramdisk 并重启
这一步必须改配置文件并重启 mysqld，SET GLOBAL 无效——它不控制启动阶段自身需要的临时文件（比如初始化日志、插件加载），也不影响复制线程和 ALTER TABLE 中间过程。
- 编辑
/etc/my.cnf或/etc/mysql/mysql.conf.d/mysqld.cnf，在[mysqld]段下加：tmpdir = /data/mysql_tmp
- 确保 MySQL 用户能访问：
sudo chown mysql:mysql /data/mysql_tmp（属主必须是运行 mysqld 的用户） - SELinux 开启时要打标签：
sudo semanage fcontext -a -t mysqld_tmp_t "/data/mysql_tmp(/.*)?" && sudo restorecon -Rv /data/mysql_tmp - 重启服务：
sudo systemctl restart mysqld - 登录后验证：
SHOW VARIABLES LIKE 'tmpdir';应返回/data/mysql_tmp
容易被忽略的三个硬伤点
90% 的失败不是命令写错了，而是栽在这三处：
- 挂载点目录权限缺执行位（
chmod 755不是 700）——MySQL 进程需要进入目录，不是只读写 - SELinux 上下文没重打（
restorecon漏了），日志里只报Can't create/write to file，看不出是安全策略拦的 - 多实例共用同一个
tmpdir路径——不同 mysqld 进程可能生成同名临时文件，导致崩溃或查询失败
如果业务有长事务或未提交 DML，ibtmp1 文件仍可能长期不缩容，但这和 tmpdir 无关，那是 innodb_temp_data_file_path 控制的另一套机制。
