真正该做的是优化查询避免生成大临时表，而非单纯调大tmpdir；需先检查索引、字段类型一致性、join_buffer_size，并联动调整tmp_table_size、max_heap_table_size及tmpdir路径至独立NVMe盘。
调大磁盘临时空间只是掩盖问题，不是解决办法。MySQL 的 tmpdir 空间再大，也无法绕过“JOIN 后无法走索引导致必须落盘”这个根本瓶颈。真正该做的，是让查询压根不生成那么大的临时表。
为什么增大 tmpdir 容量后还是慢甚至失败？
常见现象：Copying to tmp table on disk 持续几十秒、Created_tmp_disk_tables 暴涨、磁盘 IO 占满但查询仍超时。这是因为：
- 磁盘临时表本质是中间结果失控的“症状”，不是病因
- 即使
tmpdir在 SSD 上，顺序写入 + 随机读取仍比内存操作慢 100–1000 倍 - MyISAM 临时表不支持事务、无并发控制，高并发下容易锁住
tmpdir目录 - 日志里出现
The table 'sql_abc123' is full，往往不是磁盘满，而是max_heap_table_size和tmp_table_size中较小值被突破（二者必须同时调大才生效）
哪些 JOIN 场景真需要调大 tmpdir？
极少数可接受的场景，仅限于临时性、低频、可控的数据导出或报表预处理：
- 一次性跑历史数据归档：比如
CREATE TABLE archive_2025 AS SELECT ... FROM big_log JOIN dim_user ... - ETL 脚本中明确知道中间结果集稳定在几 GB 以内，且有独立高速磁盘挂载到
tmpdir - 调试阶段为定位问题临时放宽限制，配合
SET SESSION tmp_table_size = 1G和SET SESSION max_heap_table_size = 1G，但仅限单会话
注意：tmpdir 必须指向本地物理磁盘（不能是 NFS 或 tmpfs），且需确保 MySQL 进程对该路径有读写权限和足够 inodes。
调大 tmpdir 前必须先做这三件事
否则你只是在给一个漏油的发动机加更多机油：
- 确认是否真由 JOIN 引发：用
EXPLAIN FORMAT=TREE查看执行计划里有没有materialize或hash_join回退到BNL；用SHOW STATUS LIKE 'Created_tmp%'对比前后值 - 检查关联字段是否有索引且类型严格一致：比如
orders.user_id INT对users.id BIGINT就会触发隐式转换，索引失效 → 优化器被迫选错驱动表 → join_buffer 溢出 → 落盘 - 验证
join_buffer_size是否合理：默认 256KB 太小，对中等 JOIN 可设为 4MB～8MB（但别盲目调高，它会被每个 JOIN 操作独占一份）
真要调 tmpdir，得配一套最小可行方案
单独改 tmpdir 路径没用，必须联动调整底层约束：
- 在
my.cnf中同步设置：tmp_table_size = 256M、max_heap_table_size = 256M、join_buffer_size = 4M - 把
tmpdir指向一块空闲的 NVMe 盘，例如tmpdir = /mnt/nvme/mysql-tmp，并确保该路径chown mysql:mysql且chmod 1777 - 禁用 MyISAM 临时表（避免锁表）：
internal_tmp_mem_storage_engine = TempTable（MySQL 8.0+） - 监控是否生效：
SELECT @@tmp_table_size, @@max_heap_table_size, @@tmpdir;
复杂点在于：临时表膨胀从来不是孤立参数问题，而是索引缺失、驱动表误判、字段类型不匹配、排序字段未覆盖这几个条件叠加的结果。改配置前，先跑一遍 EXPLAIN ANALYZE，看清哪一行在写磁盘、为什么写——这才是最省时间的操作。
