为提高效率，请提供以下信息，问题描述清晰能够更快得到解决：
【TiDB 版本】
4.0.8
【问题描述】
tmp-storage-path目录使用超过600G, SQL语句执行完之后,会回收临时磁盘吗?
tmp-storage-quota设置了会 返回 Out Of Global Storage Quota! 错误,这个参数建议设置吗?
tmp-storage-path太大要怎么处理呢?
若提问为性能优化、故障排查类问题，请下载脚本运行。终端输出的打印结果，请务必全选并复制粘贴上传。
这些好多天之前的文件可以直接删除吗?
理论上，tmp 目录下的文件，在 sql 执行完成后，会释放对应的空间。上面的问题确实看起来可能是非预期的现象 ~
lsof chunk.ListInDisk-xxxx 看一下 这些文件是否还被 tidb 持有，来释放下磁盘空间，理论上不会有什么影响的 ~好的,感谢
这个也需要看下哈，这些文件是否仍然被 tidb 持有 ~
好的,
请问下，3 月 16 日的 chunk.ListInDisk-xxxx 相关的文件在确认 SQL 执行完毕，且 TiDB 不再占用后。删除该文件空间是否释放，以及 TiDB Server 是否因删除该文件出现异常现象 ？
另外，为了进一步排查这个问题，您那里方便提供下，下面的信息吗？
以上，辛苦了，谢谢 ~
好的，收到，这边分析下。如果有进度，会及时跟帖 ~
另外，辛苦观察下上述现象是否是 100% 可以复现的，比如，当出现使用 /tmp 目录的 sql ，并且在该 sql 执行完毕后，/tmp 的空间是否释放。以及记录下使用 /tmp 目录的 sql 的 explain analyze 的执行计划是怎样的 ~
以上，辛苦了，谢谢 ~
附件里的sql是每10分钟跑一次,和 /tmp目录下chunk.ListInDisk文件的生成时间刚好能对上,是100%复现的
执行计划有时候用到disk,有时候没有用到disk,具体信息都在附件里了
附件.txt (6.9 KB)
好的，收到，感谢回复，这边再看下，如有进度会及时跟帖 ~
您好，这个问题目前定位是因为在 v4.0.8 中，Shuffle 算子的 Close 函数没有将 worker 所持有的 Executor 一并 Close 掉，导致了资源泄漏。当前您那里的 SQL 语句和这个的情况描述相符。
目前有以下三个方案来解决这个问题：
方案一：可以通过将 window 算子的并发度 tidb_window_concurrency 调整到 1, 关闭 Shuffle 加速Window function 的功能，来避免落盘文件不删除的问题。可能会导致 SQL 有一定的性能回退，这块需要注意，建议根据当前业务情况进行评估。
方案二：定期删除 /tmp/…/tmp-storage 里的文件。
方案三：如果机器内存够用，建议调大 tidb_mem_quota_query 来避免落盘。
该问题预计会在 4.0.13 中 fix ，后续可以关注官网的发版信息 ：
好的,感谢
你好，
tidb v5.4.1 也出现了同样的问题，并且这个文件还在持续增长，也不敢删除，请帮忙排查
谢谢
[app_tidb@ip-xxxx tmp-storage]$ ls -lh chunk.ListInDisk-92614559701
-rw------- 1 app_tidb app_tidb 297G Jan 3 05:43 chunk.ListInDisk-92614559701
[app_tidb@ip-xxx tmp-storage]$ lsof chunk.ListInDisk-92614559701
lsof: WARNING: can't stat() tracefs file system /sys/kernel/debug/tracing
Output information may be incomplete.
COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME
tidb-serv 8893 app_tidb 308u REG 259,1 323027055616 79691977 chunk.ListInDisk-92614559701