MariaDB中/tmp目录下形如/tmp/MYXFhjiU的临时文件是什么？

你观测到的路径为/tmp/MY*、仅出现在已删除文件句柄中的文件，是MySQL/MariaDB的内部隐式排序临时文件，和你已知的#sql_xxx.MAI格式的Aria存储引擎显式临时表属于不同类别的临时文件。

核心特征说明 #

• 为什么在目录中看不到：这类文件创建后会立即调用unlink从文件系统目录项中移除，仅持有文件句柄的MySQL进程可以读写，因此ls命令无法扫描到，只有通过lsof查看进程打开的已删除文件才能捕捉，和你抓取到的系统调用中(deleted)标记完全匹配。
• 写入特征对应逻辑：32/64KB的块大小是MySQL排序运算的默认刷盘粒度，当需要排序的数据集超出内存排序缓冲区容量时，MySQL会自动将中间结果分片写入这类临时文件，完成外部排序后再合并结果。
• 夜间导入后高写入的触发原因：大规模数据导入后通常会伴随索引重建、批量ORDER BY/GROUP BY/DISTINCT查询、大表关联运算等操作，这类操作如果涉及的数据集超过内存缓冲区阈值，就会触发大量临时文件落盘写入，峰值达到300~500MB/s属于典型的外部排序负载特征。
• 重启无法立即恢复的原因：MySQL开启崩溃恢复机制后，重启时会自动完成未提交事务回滚、未结束的索引构建等残留操作，这类操作依然会触发排序临时文件生成，因此会出现重启后持续1~2小时卡顿的现象，本质是导入任务触发的重负载运算还在后台执行。

优化建议 #

• 卡顿期间执行show processlist排查运行中的慢查询，定位触发大规模排序的SQL语句，针对性优化索引或者调整查询逻辑
• 适当调大sort_buffer_size、tmp_table_size、max_heap_table_size参数，尽可能让临时运算在内存中完成，减少落盘写入
• 调整夜间导入任务逻辑，采用分批导入、分步建索引的方式，避免一次性触发全量大规模排序运算
• 可将tmpdir参数指向读写性能更好的SSD存储分区，缓解临时文件写入带来的系统卡顿

内容的提问来源于stack exchange，提问作者Klaudijus Petrosius