MySQL修改tmpdir后启动失败主因是权限不足或SELinux拦截，需确保mysql用户拥有读写执行权限并正确打SELinux标签，禁用NFS/FUSE路径，动态设置仅影响新连接且不能替代配置文件修改。
修改 tmpdir 配置后 MySQL 启动失败
你是否在配置MySQL临时目录时遇到过启动失败的问题？明明在配置文件中正确设置了 tmpdir 路径，但重启MySQL服务后却直接报错退出。查看错误日志，通常会看到 Can't create/write to file '/new/path/xxx' (Errcode: 13) 或 mysqld: File './ib_logfile0' not found 这类提示。先别急着检查路径拼写，问题的核心往往在于系统权限或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 是否生效
你当然可以通过SQL命令 SET GLOBAL tmpdir = '/new/path'; 动态调整临时目录。但这里存在一个关键限制：此修改仅对命令执行后新建的连接会话生效。所有已存在的连接、MySQL内部系统线程（如复制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）时，MySQL可能在内存创建临时表（MEMORY引擎）。若内存不足，则会降级为磁盘临时表，其存放位置正是tmpdir。 - 数据导入：使用
LOAD DATA INFILE命令导入本地文件时，数据会先暂存至tmpdir，再进行解析与加载。 - 主从复制：即使在从库上，执行
CREATE TEMPORARY TABLE等语句时，也会利用tmpdir路径存放相关文件，尽管临时表本身仅在会话生命周期内可见。
多实例共用一个 tmpdir 的风险
为管理方便而让多个MySQL实例共享同一临时目录？这种做法风险极高。不同实例的 mysqld 进程运行时，可能生成文件名完全相同的临时文件（例如均命名为 SQL_abc123.MYD）。这将导致数据意外覆盖、服务崩溃，或引发难以排查的随机查询失败。
更稳妥的配置方案是：
- 为每一个MySQL实例分配专属的、独立的
tmpdir子目录。例如：/data/mysql1/tmp、/data/mysql2/tmp。 - 尽量避免使用
/tmp或/var/tmp这类操作系统级共享目录。即使在路径中添加实例名前缀，也无法完全避免进程间的文件名冲突。 - 若磁盘I/O成为性能瓶颈，更合理的方案是为每个实例配置独立的SSD分区，而非让它们争抢同一路径的I/O资源。
综上所述，修改MySQL临时目录看似仅是调整一个配置参数，实则涉及系统权限、SELinux安全策略、内核挂载属性及多实例协调。任一环节疏漏都可能埋下隐患，导致在业务高峰期或凌晨时段，一个普通慢查询因临时目录问题而卡死，且排查困难。正所谓细节决定成败，在MySQL配置优化中体现得尤为明显。
