MySQL修改tmpdir后启动失败主因是权限不足或SELinux拦截，需确保mysql用户拥有读写执行权限并正确打SELinux标签，禁用NFS/FUSE路径，动态设置仅影响新连接且不能替代配置文件修改。
修改 tmpdir 配置后 MySQL 启动失败
常见现象是改完配置重启服务时直接报错退出，日志里出现类似 Can't create/write to file '/new/path/xxx' (Errcode: 13) 或 mysqld: File './ib_logfile0' not found —— 这往往不是 tmpdir 本身的问题，而是权限或 SELinux 拦截了。
实操建议：
-
tmpdir目录必须由mysql用户（非 root）可读、可写、可执行，用chown mysql:mysql /path/to/tmp和chmod 755 /path/to/tmp确保 - 如果系统启用了 SELinux（如 CentOS/RHEL 默认开启），需打标签：
semanage fcontext -a -t mysqld_tmp_t "/path/to/tmp(/.*)?"，再执行restorecon -Rv /path/to/tmp - 不要把
tmpdir设在 NFS 或 FUSE 挂载点上，MySQL 明确不支持这类文件系统用于临时目录
运行时动态设置 tmpdir 是否生效
可以执行 SET GLOBAL tmpdir = '/new/path';，但仅对后续新连接的临时表、排序等操作生效；已存在的连接、内部线程（如复制 IO 线程）、崩溃恢复过程仍用启动时加载的值。
这意味着：
- 该命令不能替代配置文件修改，尤其无法解决启动阶段的临时文件需求（如
ALTER TABLE重建表时的中间文件） - 动态设置后需确认是否真正生效：
SELECT @@tmpdir;，注意返回值末尾是否有意外空格或换行 - 某些版本（如 MySQL 5.7.29+）在严格模式下会拒绝将
tmpdir设为/tmp（因安全性限制），需改用其他路径
tmpdir 影响哪些具体操作
它不只是“放临时表的地方”，MySQL 在多个关键路径中硬依赖该目录：
- 内部排序（
ORDER BY、GROUP BY）超出sort_buffer_size时，落盘到tmpdir下的MYD/MYI文件 - 创建隐式临时表（比如含
DISTINCT+GROUP BY的复杂查询），引擎为MEMORY失败后会退化为磁盘表，存于此目录 -
LOAD DATA INFILE的本地导入过程，会先将数据暂存到tmpdir再解析 - 主从复制中，从库执行
CREATE TEMPORARY TABLE语句时，也会用到此路径（尽管临时表本身只在会话内可见）
多实例共用一个 tmpdir 的风险
看似省事，实际极易引发冲突：不同实例的 mysqld 进程可能生成同名临时文件（如 SQL_abc123.MYD），导致数据覆盖、崩溃或不可预测的查询失败。
稳妥做法：
- 每个 MySQL 实例必须独占一个
tmpdir子目录，例如：/data/mysql1/tmp、/data/mysql2/tmp - 避免使用
/tmp或/var/tmp这类系统级共享目录，即使加了实例前缀也不保险（进程间无命名隔离） - 若磁盘 I/O 是瓶颈，宁可为每个实例配独立 SSD 分区，也不要复用路径
临时目录这事，看着只是改个路径，但牵扯权限、安全模块、内核挂载属性和多实例协调——漏掉任意一环，都可能让某个凌晨三点的慢查询突然卡死，还查不出原因。
