phpMyAdmin 的 tmp 目录必须手动清理，因其默认在 /usr/share/phpmyadmin/tmp 写入 session、导出 ZIP、SQL 缓存等文件，这些文件不自动过期且不受 PHP session.gc_maxlifetime 管控，长期堆积易致磁盘满。
因为 phpmyadmin 自身不清理临时文件和缓存，这些文件会持续堆积，最终触发 no space left on device 错误——这不是“可能”，而是小内存 vps 或长期未维护服务器上的高频故障。
phpMyAdmin 的 tmp 目录为什么必须手动清理？
phpMyAdmin 默认在 /usr/share/phpmyadmin/tmp（或自定义路径）写入 session 文件、导出临时 ZIP、SQL 执行缓存等。这些文件不会自动过期，也不受 PHP 的 session.gc_maxlifetime 管控：
- 导出大表时生成的
export_*.zip文件常驻磁盘，哪怕下载完成也不会被删 - 登录 session 文件权限若为
root:root，后续重装 phpMyAdmin 会因不可写报错，但更危险的是残留文件里可能含明文凭证缓存 - 某些版本在导入 SQL 失败后，会在 tmp 下留下未清理的
import_*.sql副本，单个可达百 MB
哪些缓存类型容易被忽略？
phpMyAdmin 本身不依赖 OPcache 或 Redis，但它运行在 PHP 环境中，而框架层/系统层缓存会交叉影响：
-
storage/framework/cache/data/（Laravel 项目共用）：phpMyAdmin 若嵌入 Laravel 后台，其缓存项会混入该目录，php artisan cache:clear不识别 phpMyAdmin 产生的 key -
/tmp/opcache/：若启用了opcache.file_cache，PHP 重启不清理，rm -f /tmp/opcache/*必须单独执行 -
~/.composer/cache/：宝塔或一键脚本部署时常以 root 运行 composer，composer clear-cache不会自动触发，du -sh ~/.composer/cache/files经常显示数 GB 占用
清理时最常踩的坑是什么？
直接 rm -rf /usr/share/phpmyadmin/tmp 看似干净，但遗漏关键残留：
- Web 服务配置没删：
/etc/apache2/conf-enabled/phpmyadmin.conf或 Nginx 的/www/server/panel/vhost/nginx/phpmyadmin.conf仍存在，重启后路径继续可访问 - MySQL 用户没删：
pma@localhost或phpmyadmin@%仍在mysql.user表中，拥有查系统表权限，是提权跳板 - session 目录权限错误：清完 tmp 后未重设
chown www-data:www-data /usr/share/phpmyadmin/tmp，下次登录直接 500
真正要清理的从来不是“phpMyAdmin 的缓存”，而是它暴露在公网的入口 + 残留的权限 + 与其他 PHP 应用共享的底层缓存路径——这几个点漏掉任何一个，都等于只擦了门把手，没锁门。
立即学习“PHP免费学习笔记（深入）”；
