必须用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 和权限错配。

• 先创建挂载点：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 中间过程。

Linux Security Scanner

Linux 安全审计工具，检查 SSH 配置、开放/监听端口、防火墙规则（ufw/iptables/nftables）、失败登录尝试、sudoers 权限...

下载

• 编辑 /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 控制的另一套机制。